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Preface 


The  purpose  o-f  this  study  was  to  evaluate  the 
feasibility  of  implementing  a  computerized  database 
management  system  to  support  the  AFIT  thesis  process. 

A  database  was  designed  and  implemented  using  a 
relational  database  management  system.  Although  the 
database  was  limited  to  thesis  topics  and  advisors,  this 
system  would  be  useful  for  other  supervisory  and 
adni n i strat i ve  functions,  r 

I  wish  to  express  my  appreciation  to  my  advisor, 

Dr.  Robert  B.  Weaver,  for  his  guidance  and  assistance 
throughout  this  research  project.  I  am  also  indebted  to 
Major  Charles  E.  Beck  for  initially  suggesting  the  topic, 
and  to  Dr.  Terrance  M.  Skelton  and  Major  John  A.  Stibravy 
for  their  cooperation  in  developing  and  implementing  the 
database.  Finally,  I  would  like  to  give  special  thanks  to 
my  wife,  Leslie,  and  my  children,  Kristin  and  John,  for 
their  patience,  understanding,  and  encouragement  during  this 
academic  year. 


i  i 


Joseph  D.  Perkumas 


Tabl?  of  Contents 


Page 


Preface .  i  i 

List  of  Figures . v 

List  of  Tables . vi 

List  of  Printouts . vii 

Abstract . .  vi  i  i 

I.  Introduction  ...........  .  I 

General  Issue  ...  .  1 

Specific  Problem  .  3 

Background  .  .....  3 

Database  Systems  .  3 

Data .  3 

Hardware  .  6 

Software  . .  6 

Users . 6 

Architecture  of  a  Database  System  .  .  7 

Relational  Data  Mode)  ........  8 

Relational  Algebra  .  9 

Scope . 13 

Research  Objectives  .  13 

II.  Methodology  .....  .  14 

Introduction  .  14 

Description  . .  14 

Logical  Database  Design  .......  14 

Requirements  Analysis  .  16 

Data  Modeling  . .  17 

Integration .  17 

Schema  Development  .  17 

Physical  Database  Design  .  .  18 

Data  Representation .  18 

Selection  of  Entry  Points  and 

Access  Methods  .  18 

Data  Allocation .  18 

Normalization  .  1? 

III.  Results  and  Discussion .  22 

Introduction  .  22 


Pag# 


Description  .  . .  22 

Logical  Database  Design  .  22 

Requirements  Analysis  and  Data 

Model  ing .  22 

Integration .  23 

Schema  Development  .  24 

Physical  Database  Design  .  25 

Data  Representation .  25 

IV.  Conclusions  and  Recommendations .  26 

Summary  . .  26 

Conclusions .  26 

Recommendations  .........  .  27 

Appendix  A:  Requirements  Analysis  Inputs  and 

Results .  28 

Appendix  B:  Guide  to  THESIS  Database  Using  R:base 

Series  6000  47 

Bibliography  .  78 

Vita .  79 


List  of  Tables 


Page 


Database  Model  Advantages  and  Disadvantages  5 

Thesis  Advisor  Data  Elements  .  43 

Thesis  Topic  Data  Elements . 45 

R:base  Commands .  5 6 


Li  st  of  Printouts 

Printout  Page 

B.l  Listing  o-f  THESIS  Database  Rules .  62 

B.2  Example  o-f  DEFINE .  62 

B.3  Attributes  in  Relation  ADVISOR . 63 

B.4  Attributes  in  Relation  ARES5 .  64 

B.5  Attributes  in  Relation  CATLIST  .  64 

B.6  Attributes  in  Relation  KEYLIST  .  65 

8 .7  Attributes  in  Relation  STLIST  .  65 

B.8  Attributes  in  Relation  TOPIC  .  . .  65 

B.9  Attributes  in  Relation  TOPOUT  .  66 

B.10  Listing  o-f  Relation  CATLiST . 68 

B.ll  Listing  of  Relation  STLIST  . .  68 

B.  12  Listing  o-f  Relation  KEYLIST .  69 

B.  13  Listing  of  RESEARCH. RPT .  71 

B .  1 4  Listing  of  TOPIC. RPT .  72 

B. 15  Sample  Output  of  ADV.RPT1  and  ADV.RPT2  ...  74 

B.16  Sample  Output  of  ADV.RPT3  .  75 

B.l 7  Sample  Output  of  ARES. RPT  .  76 

B . 1 8  Sample  Output  of  T0P.RPT1  and  TOP . RPT2  .  .  . 


v  i  i 


77 


AF I T/GLM/LSH/85S-63 


Abstr ac  t 

The  purpose  of  this  rtscarch  was  to  evaluate  the 
feasibility  of  implementing  a  computerized  database 
management  system  to  support  the  AFIT  thesis  process. 

The  methodology  consisted  of  both  logical  and  physical 
database  design.  User  requirements  were  determined  through 
an  analysis  of  the  existing  system  and  interviews,  and  a 
system- i ndependen t  description  of  the  database  was 
developed.  The  database  was  implemented  using  R:base  Series 
4000,  a  relational  database  management  system,  on  a 
Burroughs  microcomputer  system.  A  guide  to  the  database  is 


i  nc 1 uded . 


DESIGN  AND  IMPLEMENTATION  OF  A  RELATIONAL 


DATABASE  MANAGEMENT  SYSTEM  FOR  THE  AFIT  THESIS  PROCESS 


I .  Introduct i on 


General  I ssue 

To  be  eligible  -for  award  of  the  Master  of  Science 
degree,  each  student  in  the  School  of  Systems  and  Logistics 
must  complete  an  independent  research  investigation  on  a 
problem  of  interest  to  the  Department  of  Defense  (DOD>  and 
present  the  results  of  the  research  as  a  formal  thesis 
<1:50).  The  Department  of  Communication  and  Research 
Methods  <LSH)  is  responsible  for  the  supervision  and 
acini  n  i  strat  i  on  of  the  thesis  research  program.  LSH  is 
specifically  responsible  for: 

1.  Administering  and  supervising  graduate  thesis 
research , 

2.  Collecting  potential  research  topics, 

3.  Coordinating  faculty  review  and  screening  of  topics 

4.  Preparing  faculty-approved  topics  for  student 
rev i ew , 

5.  Maintaining  a  listing  of  the  qualifications  and 
interests  of  potential  Thesis  Advisors  for  student 
use , 

6.  Monitoring  selection  of  the  Thesis  Advisors  and 
other  members  of  the  Thesis  Committees  assigned  to 
work  with  the  graduate  students  on  their  research 
efforts, 

7.  Administratively  controlling  the  use  of  research 
surveys/quest i onna i res  for  gathering  information 
related  to  research  topics, 

8.  Prescribing  the  format  and  requirements  for 
preparation  of  the  final  copy  of  the  thesis, 


9.  Reviewing  the  -final  cop/  of  the  thesis  to  assure 
compliance  with  the  prescribed  format,  and 
10.  Supervising  the  publication  and  distribution  of 
student  theses  in  accordance  with  applicable 
directives.  (1:64-65) 

A  student  begins  the  thesis  process  by  selecting  a 
topic.  To  assist  the  student,  a  list  of  potential  topics 
from  DOD  organizations  and  the  faculty  is  maintained  in  a 
file  in  the  School  library  (8:5).  This  list  includes  a 
working  title,  a  statement  of  the  problem,  a  faculty 
contact,  and  information  sources  on  background,  data,  and 
expertise.  The  Air  Un i versi ty  Compendi urn  of  Research  Top i cs 
and  theses  completed  by  recent  graduates  are  also  maintained 
in  the  library  (8:5). 

Once  a  topic  is  selected,  the  student  must  then  select  a 
thesis  advisor  interested  in  working  on  that  topic.  To 
assist  the  student  in  this  process,  a  file  of  qualified 
faculty  members  is  also  maintained  on  reserve  in  the  library 
(8:8).  This  file  includes  a  list  of  qualified  thesis 
advisors,  adjunct  readers,  interns,  and  committee  members;  a 
topical  index  of  thesis  advisors;  and  a  brief  description  of 
each  faculty  member's  academic  rank/job  title,  education, 
relevant  experience,  professional  activity,  and  statement  of 
research  interest. 

Although  these  sources  are  available,  because  of  their 
lack  of  integration,  they  are  not  used  to  their  fullest 
potent i al . 


Spec  i  f  i  c  Problem 

The  problem  is  that  an  integrated  source  o-f  thesis 
topics  and  advisors  does  not  exist  in  the  School  o-f  Systems 
and  Logistics.  Can  an  integrated  computerized  database  and 
database  management  system  be  applied  to  correct  this 
def  i  c  i  ency? 

Background 

Database  Systems.  In  An  Introduct i on  to  Database 
Systems,  C.J.  Date  describes  a  database  system  as  a 
computet — based  recordkeeping  system  composed  o-f  data, 
hardware,  software,  and  users  whose  overall  purpose  is  to 
record  and  maintain  information  <2:3-4). 

Data.  A  database  may  be  defined  as  "a  collection 
of  stored  operational  data  used  by  the  application  systems 
of  some  particular  enterprise"  <2:7>.  This  data  is  both 
integrated  and  shared.  "Integrated"  refers  to  the 
consolidation  of  distinct  data  files  so  redundancy  is  either 
partially  or  wholly  eliminated.  "Shared"  refers  to  the 
condition  in  which  the  same  data  may  be  used  by  several 
different  users  <2:5).  Databases  may  be  modeled  as 
hierarchies,  networks,  or  relations  depending  on  the 
relationships  that  exist  between  data  elements  (see  Figure 
1.1).  Hierarchical  and  network  data  models  both  consist  of 
several  levels  of  data  elements.  In  a  hierarchy, 
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Figure  1.1.  Database  Models 

data  elements  at  lower  levels  are  subordinate  to  single  data 
elements  in  the  next  higher  level.  The  single  data  element 
at  the  top  of  the  model  is  called  the  root.  A  network  is  a 
more  general  structure  since  the  data  elements  at  lower 
levels  max  be  subordinate  to  more  than  one  data  element  in 
higher  levels.  A  relation  is  a  two-dimensional  table 
containing  data  elements  <10:12-13).  Relational  data  models 
will  be  discussed  more  fully  later  in  this  chapter. 

Table  1.1  lists  the  relative  advantages  and  disadvantages  of 
each  data  model.  As  the  table  indicates,  a  relational  data 
model  offers  substantial  advantages. 


Table  1.1 

Database  Model  Advantages  and  Disadvantages  <?:25> 
ADVANTAGE  DISADVANTAGE 

Hi erarchy : 

*  Optimizes  control  and  *  Old  architecture  designed 

management  of  data  only  to  optimize  hardware 

*  Eliminates  redundancy  usage 

*  Centralizes  control  #  Inflexible  to  change 

*  Improves  secur i ty  of  data  *  Data  hard  to  manipulate 

for  data  center  *  Changes  to  data  base 

greatly  affect  programs 
attached  to  i t 

*  Fixed  structure  -  data 
■  locked*  in  place  and 
inflexible 

*  Difficult  to  get  ad  hoc 
reports 

Ne  twork : 


*  Optimizes  control  and 
management  of  data 

*  Eliminates  redundancy 

*  Centralizes  control 

*  Improves  security  of  data 
for  data  center 

*  As  compared  to  hierarch¬ 
ical,  file  structure 
less  restricted  and  more 
flexible 


Re  la 

*  Optimizes  control  and 
management  of  data 

a  Designed  to  optimize 

programmer/end-user  usage 

*  Easy  to  use  -  for  al 1  user 

*  Extremely  flexible 

*  Simple  data  manipulation 

*  Changes  to  data  base  have 
no  effect  on  programs 


*  Aging  technology,  designed 
to  optimize  hardware  usage 
and  make  information  more 
accessi bl e 

*  For  high-tech  users  -  hard 
to  use 

*  Difficult  to  get  ad  hoc 
reports 

*  Complicated  structure:  hard 
to  mai ntai n 

*  Inflexible  to  change 

*  Changes  to  data  base 
greatly  affect  programs 
attached  to  i t 

i  onal  : 

*  Uses  more  hardware  resource 
(effect  can  be  minimized 
through  use  of  indexes  in 
the  data  base) 


Table  1.1  (Continued). 

Database  Model  Advantages  and  Disadvantages  (9:25) 


ADVANTAGE  DISADVANTAGE 

Rel at i onal : 

*  Designed  -for  applications 
design  and  development  to 
help  eliminate  the  backlog 

*  Eliminates  redundancy 

*  Centralizes  control 

*  Improves  security  o-f  data 
•for  data  center 

*  Easy  to  obtain  ad  hoc 
reports 


Hardware .  The  hardware  consists  o-f  the  secondary 
storage  volumes,  associated  devices,  control  units,  and 
channel s  (2:5) . 

Software .  A  database  management  system  (DBMS)  is 
the  software  that  exists  between  the  physical  database 
itself  and  the  users  of  the  system.  All  access  to  the 
database  is  through  the  DBMS  (2:6).  A  DBMS  contains  two 
specific  functions:  a  Data  Definition  Language  (DDL)  and  a 
Data  Manipulation  Language  (DML) .  The  DDL  provides  a 
definition  or  description  of  data  elements,  and  the  DML 
supports  the  manipulation  of  these  elements  (2:21).  R:base 
Series  6000,  a  relational  DBMS  for  microcomputers  from 
Microrim  Inc.  was  used  on  this  project. 

Users .  C.J.  Date  defines  three  classes  of  users  of 
a  database  management  system:  application  programmers, 
end-users,  and  the  database  administrator  (DBA).  The 
applications  programmer  is  responsible  for  writing 
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Figure  1.2.  The  Three  Levels  of  Architecture 


application  programs  typically  in  a  high-level  language  that 
operate  on  the  database  by  either  retrieving,  creating, 
deleting,  or  modifing  information.  The  end-user,  usually 
accessing  the  database  through  a  terminal,  may  also  perform 
these  functions;  however,  he  or  she  is  primarily  concerned 
with  retrieval  of  data.  The  database  administrator  is 
responsible  for  overall  control  of  the  system  (2:6). 

Arch i tec ture  of  a  Database  System.  The  architecture  of 
a  database  system  is  divided  into  three  levels:  internal, 
conceptual,  and  external  (see  Figure  1.2).  The  internal 
level  involves  the  way  data  is  actually  stored  and  is 
defined  by  the  internal  schema.  The  external  level  refers 
to  the  way  data  is  viewed  by  the  individual  user  and  is 


de-fined  by  an  external  schema.  The  conceptual  level 
represents  the  entire  information  content  of  the  database 
and  is  defined  by  the  conceptual  schema.  Given  these  three 
levels,  two  levels  of  mapping  exist:  one  defines  the 
correspondence  between  the  internal  and  conceptual  levels 
while  the  other  defines  the  correspondence  between  the 
conceptual  and  external  levels  (2:21-24). 


Rel at i onal  Data  Model .  In  a  relational  data  model ,  a 
relation  is  a  two-dimensional  table  conforming  to  a  set  of 
simple  rules.  These  rules  are: 


1.  Within  a  relational  system,  the  table  must  contain 
only  one  type  of  record.  Each  record  has  a  fixed 
number  of  fields,  all  of  which  are  explicitly  named 
The  database  will  usually  contain  numerous  tables, 
so  that  different  kinds  of  records  are  held  in 
different  tables; 

2.  Within  a  table  the  fields  are  distinct,  and 
repeating  groups  are  not  allowed; 

3.  Each  record  within  a  table  is  unique;  there  are  no 
duplicate  records; 

4.  The  order  of  the  records  within  the  table  is 
indeterminate.  The  records  may  come  in  any  order, 
and  there  is  no  predetermined  sequence; 

5.  The  fields  within  any  column  take  their  values  from 
a  domain  of  possible  field  values.  The  same  domain 
can  be  used  for  many  different  field  types,  perhaps 
in  several  tables; 

6.  Finally,  new  tables  can  be  produced  on  the  basis  of 
a  match  of  field  values  from  the  same  domain  in  two 
existing  tables.  The  formation  of  new  tables  from 
existing  tables  is  the  essence  of  relational 
processing.  (5:27) 

Two  typical  tables  (relations)  are  shown  in  Figure  1.3.  Th< 
columns  of  a  table  are  known  as  attributes,  while  the  rows, 
containing  related  attributes,  are  known  as  tuples  (rhymes 


Figure  1.3.  Two  Typical  Relations 

with  "couples")  (2:63).  The  degree  of  a  relation  is  the 
number  of  columns,  while  the  cardinality  of  a  relation  is 
the  number  of  rows  (3:28).  The  relation  ADVISOR  shown  in 
Figure  1.3  has  four  columns  (attributes)  or  a  degree  of  four 
and  five  columns  (tuples)  or  a  cardinality  of  five.  Each 
column  is  headed  by  the  name  of  the  attribute,  e.g.,  STATUS. 
The  intersection  of  a  row  and  column  in  a  table  is  known  as 
an  attribute  occurrence  or  attribute  value,  e.g.,  Jones 
(4:37).  In  traditional  terms,  a  table  resembles  a  file,  a 
row  resembles  a  record  (occurrence,  not  type),  and  a  column 
resembles  a  field  (type,  not  occurrence)  (2:93). 

Rel at i onal  Algebra.  Relational  algebra  defines  the  set 
of  high  level  operations  which  manipulate  the  database  to 
produce  new  relations.  Relational  algebra  includes  the 
relational  operations  (SELECT,  PROJECT,  and  JOIN)  and  the 
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Figure  1.4.  Relational  Operations  (5:33) 


set  operations  (UNION,  INTERSECTION,  and  DIFFERENCE)  (5:31). 
The  six  operations  are  illustrated  in  Figure  1.4. 

The  SELECT  operator  creates  a  new  table  by  taking  a 
horizontal  subset  o-f  an  existing  table,  that  is,  the  new 
table  consists  o-f  all  rows  of  an  existing  table  that  satisfy 
some  specified  condition  (2:75).  For  example,  to  select  all 


rows  from  the  relation  ADVISOR  where  STATUS  equals 


SELECT  ALL  FROM  ADVISOR  WHERE 
STATUS  EG  Q 


PROJECT  TEMPI  FROM 
ADVISOR  USING  ADWUM 
NAME 

TEMPI 


ADLNUM!  NAME  ! STATUS ! OFFSYM 


0001 

!  Brown 

0002 

'Smith 

0005 

!  Green 

ADWUM!  NAME  ! 

0001 

! Brown  i 

0002 

! Smith  : 

0003 

! Jones 

0004 

iWhite 

0005 

'Green 

JOIN  TOPIC  USING  ADVNUM  WITH  ADVISOR  USING  ADVNUM 
FORMING  TEMP2 


TEMP2 


TOPNUM 


TITLE  lADLNUMi  NAME  ! STATUS ! OFFSYM ! 


0001  ! Acqu i si t i on '  0002  'Smith 


0002  i  Rel i abi 1 i  ty  S  0001  SBrown 


0003  '  Contracts  0004  '.Whits 


Figure  1.5.  Relational  Operation  Examples 

qualified  <Q)  would  result  in  a  new  table  with  only  three 
rows  (see  Figure  1.5). 

The  PROJECT  operator  creates  a  new  table  by  taking  a 
vertical  subset  o-f  an  existing  table,  that  is,  the  new  table 
consists  of  all  columns  of  an  existing  table  that  satisfy 
some  specified  condition  <2:75).  For  example,  to  project 
all  columns  from  the  relation  ADVISOR  using  advisor  number 


and  last  name  would  result  in  a  new  table  with  -five  rows  but 
only  two  columns  <see  Figure  1.5).  Although  duplicate  rows 
are  not  allowed  in  a  table  and  should  be  removed 
automatically,  a  separate  operation  is  required  in  some 
systems  (7:20). 

The  JOIN  operator  creates  a  new  table  by  adjoining,  or 
concatenating,  two  tables  each  having  a  column  de-fined  over 
some  domain  (2:76).  The  two  tables  can  have  different 
degrees  and  different  cardinalities.  The  join  operation 
works  conceptually  as  follows: 


1.  The  first  row  of  the  first  table  is  selected  and  the 
value  is  extracted  from  the  column  being  used  for 
the  join. 

2.  The  other  table  is  then  examined  on  the  matching 
column  taking  records  one  by  one  until  a  match  is 
found  between  the  values  in  the  two  columns. 

3.  When  a  match  is  found,  a  new  record  is  created  for 
the  new  table.  The  record  is  formed  by  joining 
together  the  rows  from  the  two  tables. 

4.  The  process  continues  until  the  end  of  the  second 
table  is  reached. 

5.  The  process  is  then  repeated  taking  the  next  row 
from  the  first  table  and  scanning  all  the  rows  of 
the  second  table  until  eventually  the  first  table  is 
exhausted.  (5:27) 

To  join  the  two  relations  TOPIC  and  ADMISOR  using  advisor 
number  would  result  in  a  new  table  consisting  of  three  raws 
and  six  columns  (see  Figure  1.5). 

The  union  of  two  tables  A  and  B,  A  UNION  B,  is  the  set 
of  all  rows  belonging  to  either  A  or  B  or  both.  The 
intersection  of  two  tables  A  and  B,  A  INTERSECT  B,  is  the 
set  of  all  rows  belonging  to  both  A  and  B.  The  difference 


between  two  tables  A  and  B  (in  that  order),  A  MINUS  B,  is 
the  set  of  all  rows  belonging  to  A  but  not  to  B.  For  set 
operations,  the  tables  A  and  B  must  be  union  compatible, 
that  is,  they  must  have  the  same  number  o-f  columns,  and  the 
corresponding  columns  must  be  drawn  from  the  same  domain 
(5:32)  . 

Scope 

The  scope  of  the  research  project  is  to  evaluate  the 
feasibility  of  implementing  a  computerized  database 
management  system  to  integrate  thesis  topics  and  advisors. 

Research  Object i ves 

Given  the  scope  of  the  research  project,  the  objectives 

are : 

1.  To  determine  the  information  requirements  of  a 
thesis  topic/advisor  database. 

2.  To  design  and  implement  a  relational  database  to 
supply  the  determined  needs. 


II.  Me  thodol ogy 


I n  troduc t i on 

The  particlar  methodology  -for  this  research  essentially 
-followed  the  database  design  process  described  by  Jay-Lou  i  se 
Weldon  in  Data  Base  Admi n i str at i on .  To  Weldon,  the 
objective  o-f  the  database  design  process  is  "to  produce  an 
integrated  data  base  which  is  accurate  and  secure  and  which 
supports  application  systems  in  an  e-f-ficient  manner" 

<11:89). 

Descr i p  t i on 

The  database  design  process  consists  of  two  sets  of 
design  tasks:  logical  database  design  and  physical  database 
design  (see  Figure  2.1).  Logical  database  design  is 
concerned  with  determining  user  requirements  (external 
views)  and  developing  a  system- i ndependen t  description 
(conceptual  view)  of  the  database  that  will  support  those 
requirements.  Physical  database  design  is  concerned  with  the 
actual  implementation  of  the  database  on  a  specific 
harctoiare/sof tware  system  (internal  view)  (11:90). 

Log i cal  Database  Design.  Logical  database  design 
consists  of  four  activities:  requirements  analysis,  data 
modeling,  integration,  and  schema  development.  These 


REAL  WORLD 


Log i c  a I  ! 

I 

Design  ! 

I 

I 

• 

I 

I 

I 

I 

I 

• 

• 

I 

I 

I 

l 

» 

I 

\ 

/ 

I 

l 

I 

I 

• 

i 

I 

I 

t 

I 

I 

I 

Physical  ! 

I 

I 

Design  ! 


!  Requirements  ! 
!  Analysis  ! 


g 


Data 

Mode  1 i ng 


V 


Integration  ! 


g 


Schema  i 

Development  ! 


!  Logical 

g  DB  Schema 


!  Data  ! 

!  Representation  ! 


l 

g 


Selection  o-f 
Entry  Points  & 
Access  Methods 


g 


Data 

A1 location 


l 

g 

DB  Schema 


Figure  2.1.  The  Database  Design  Process  (11:91) 
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activities  may  be  performed  in  sequence  or  in  parallel 
<11 :?1> . 

Requ i rements  Analysis.  Requirements  analysis  is 
concerned  with  determining  user  needs  -for  both  data  and  the 
operations  that  will  be  performed  on  this  data  (11:92). 

Davis  and  Olson  describe  four  strategies  for  determining 
requ i rements: 

1.  Asking  directly, 

2.  Deriving  from  an  existing  information  system, 

3.  Synthesizing  from  characteristics  of  the  utilizing 
system,  or 

4.  Discovering  from  experimentation  with  an  evolving 
information  system.  (3:480) 

In  the  asking  strategy,  requirements  are  simply  obtained  by 
asking  the  users  what  their  requirements  are.  This  strategy 
is  appropriate  for  stable,  well-defined  systems  or  those 
whose  operation  is  defined  by  law,  regulation,  or  other 
authority.  If  a  similiar  system  exists,  this  system  can  be 
used  to  determine  the  requirements  of  a  proposed  system. 

The  types  of  existing  systems  that  are  useful  in  this  regard 
i nc 1 ude 

1.  Existing  systems  that  will  be  replaced  by  the  new 
system, 

2.  Existing  system  in  another,  similiar  organization, 

3.  Proprietary  system  or  package, 

4.  Descriptions  in  textbooks,  handbooks,  industry 
studies,  etc.  (3:482) 

Since  the  information  system  provides  a  service  to  the  user, 
in  the  third  strategy,  requirements  are  determined  from  an 
analysis  of  this  using  system.  Finally,  if  the  users  are 


not  able  to  -formulate  their  requirements,  the  -fourth 
strategy  is  to  derive  an  initial  set  o-f  requirements  and 
implement  these.  This  approach  is  also  known  as  prototyping 
or  heuristic  development.  Selection  o-f  a  strategy  is  based 
on  the  overall  uncertainty  o-f  requirements.  If  uncertainty 
is  low,  asking  directly  or  deriving  from  an  existing  system 
would  be  appropriate;  whereas,  if  uncertainty  is  high, 
synthesis  or  exper imentat i on  would  be  used  (3:480-490). 

Since  uncertainty  was  low  on  this  project,  the  first  vo 
strategies  were  used. 

Data  Model i ng.  Data  modeling  is  concerned  with 
developing  an  abstract  representation,  or  data  model,  of 
each  user's  view  of  the  database.  This  involves  identifying 
basic  entities  (their  names  and  attributes)  and  the 
relationships  that  exist  between  these  entities  (11:92). 
Normalization  may  be  used  to  develop  more  efficient  models, 
and  this  technique  will  be  discussed  more  fully  later  in 
this  chapter. 

Integrat i on .  Since  several  data  models  may  be 
produced  by  the  preceding  steps,  integration  is  concerned 
with  synthesizing  these  models  into  a  single  model  from 
which  the  various  user  views  may  be  derived  (11:92).  During 
integration,  common  entities  are  identified  and 
inconsistencies  are  resolved  (11:110). 

Schema  Devel opment .  The  schema  development  step  is 
a  transition  between  logical  and  physical  database  design. 


The  previous  steps  are  independent  of  a  DBMS;  however,  a 
database  schema  is  a  description  o-f  a  database  in  the  DDL  o-f 
a  particular  DBMS.  Schema  development  is  concerned  with 
choosing  DBMS  constructs  and  combining  these  constructs  into 
a  consistent  schema  <11:93). 

Physi cal  Database  Design.  Physical  database  design  is 
concerned  with  how  the  logical  schema  is  stored  and 
accessed.  It  consists  o-f  three  activities:  data 
representation,  selection  o-f  database  entry  points  and 
access  paths,  and  allocation  of  data  to  storage  devices. 

Data  Representat i on .  Data  representation  is 
concerned  with  specification  of  data  types  (alphabetic, 
numeric,  or  alphanumeric),  field  lengths,  and  replication 
factors  (number  of  occurrences)  using  the  DDL  of  the  DBMS. 
These  specifications  may  come  directly  from  the  data 
definitions  developed  during  requirements  analysis  (11:93). 

Selection  of  En try  Points  and  Access  Methods. 
Selection  of  entry  points  and  access  methods  is  concerned 
with  the  choice  of  access  methods  for  each  entity  in  the 
database  and  how  these  data  entities  are  going  to  be  linked 
(11:93).  The  choices  are  DBMS  dependent. 

Data  A 1  location.  Data  allocation  is  concerned  with 
apportioning  the  database  to  physical  storage  devices 
(11:94).  Since  the  project  uses  a  microcomputer  system, 
storage  is  limited  to  magnetic  floppy  diskettes  and  a  single 


hard  disk  unit. 


Figure  2.2.  Normal  Form  Relations 


Normal i zat i on .  Normalization  is  a  technique  used  in 
data  modeling.  A  relation  is  in  a  particular  normal  -form 
(NF)  if  it  satisfies  certain  constraints.  Although 
C.J.  Date  describes  five  normal  forms  (2:237-265),  the 
fourth  and  fifth  forms  are  rarely  used  in  practice  <3:513), 
and  will  not  be  discussed  further.  Therefore,  normalization 
will  be  defined  as  the  process  of  transforming  unnormalized 
relations  into  relations  in  third  normal  form  <3NF>  (see 
Fi gure  2.2) . 

A  relation  is  in  INF  if  it  does  not  include  any 
repeating  groups.  The  formal  definition  is 

A  relation  R  is  in  first  normal  form  <1NF)  if  and  only 

if  all  underlying  domains  contain  atomic  values. 

(2:243) 


A  normalized  relation  can  be  represented  by  a  -flat  -file 
where  each  row  has  a  -fixed  -format  (5:63). 

A  relation  is  in  2NF  when  each  attribute  depends  on  the 
whole  key.  The  -formal  de-finition  is 

A  relation  R  is  in  second  normal  -form  (2NF)  if  and  only 
if  it  is  in  INF  and  every  non-key  attribute  is  fully 
dependent  on  the  primary  key.  (2:246) 

A  key  is  formed  from  one  or  more  attributes  and  identifies 

the  row  in  the  same  way  a  social  security  number  identifies 

an  individual.  A  candidate  key  is  a  key  which  uniquely 

distinguishes  that  row  from  any  other  row  in  the  relation. 

A  primary  key  is  a  candidate  key  in  which  no  attribute  can 

be  set  to  null.  In  a  relational  database,  every  data 

element  can  be  uniquely  addressed  by  the  relation  <R>,  the 

primary  key  value  (K),  and  the  attribute  name  (A)  (5:55-59) 

In  3NF,  each  field  depends  on  the  key,  the  whole  key, 

and  nothing  but  the  key.  The  formal  definition  is 

A  relation  R  is  in  third  normal  form  (3NF)  if  and  only 
if  it  is  in  2NF  and  every  non-key  attribute  is 
nontransi t i vel y  dependent  on  the  primary  key.  (2:248) 

If  B  is  dependent  on  A  (A — >B)  and  C  »s  dependent  on  B 

<B — >C) ,  implying  C  is  dependent  on  A,  then  C  is 

transitively  dependent  on  A  (A — >C> .  To  determine 

transitivity,  each  non-key  data  element  is  considered  in 

turn  to  determine  whether  it  is  dependent  on  any  other 

non-key  data  element  in  the  relation  (5:69). 


Although  3NF  is  a  goal  in  the  design  process,  C.J.  Date 


notes  that  the  it  is  only  a  goal,  and  the  only  necessary 
requirement  is  that  a  relation  be  in  INF  <2:239). 

Application  of  this  methodology  is  presented  in  the  next 
chap  ter . 


Ill 


Results  and  Discussion 


I n  troduc t i on . 

This  chapter  describes  the  application  of  the 
methodology  presented  in  the  previous  chapter  using  a 
microcomputer-based  relational  database  management  system. 

Descr i pt i on . 

Logical  Database  Design.  Logical  database  design  is 
concerned  with  determining  user  requirements  and  developing 
a  system-independent  description  which  will  be  implemented 
during  physical  database  design.  As  previously  described, 
logical  database  design  consists  of  requirements  analysis, 
data  modeling,  integration,  and  schema  development. 
Requirements  analysis  and  data  modeling  were  combined  on 
this  project. 

Requ i rements  Analysis  and  Data  Modeling. 
Requirements  analysis  is  concerned  with  determining  user 
needs  for  both  data  and  the  processing  of  this  data.  Data 
modeling  involves  developing  an  abstract  represen  tat i on  of 
each  user's  view  of  the  data.  Since  the  thesis  process  is  a 
relatively  stable,  well-defined  system,  the  first  two 
requirements  analysis  strategies  were  employed.  The 
existing  system,  consisting  of  the  thesis  advisor  and  thesis 
topic  files  in  the  School  library,  were  reviewed.  These 


-files  contained  three  types  o-f  reports  for  thesis  advisors: 
a  Personal  Data  Sheet;  a  List  o-f  Qualified  Thesis  Advisors 
(Q),  Adjunct  Readers  <A> ,  Interns  (I),  and  Committee  Members 
(C);  and  a  Topical  Index  of  Thesis  Advisors;  the  files 
contained  one  report  for  thesis  topics:  Thesis  Research 
Topic  Proposal  (see  Appendix  A  for  representat i ve  examples). 
Initial  interviews  were  also  conducted  with  Maj  John  A. 
Stibravy  and  Dr.  Terrance  M.  Skelton,  who  are  responsible 
for  these  files.  They  provided  copies  of  LS  Operating 
Instruction  (01)  53-4  and  an  AFIT/LSH  letter  which  described 
these  programs  (see  Appendix  A).  Based  on  these  documents, 
an  initial  list  of  data  elements  was  identified.  This  was 
modified  during  subsequent  interviews  with  Maj  Stibravy  and 
Dr.  Skelton.  Each  data  element  was  assigned  a  name,  data 
type,  and  length,  and  then  whether  it  was  key  was  determined 
(see  Table  A.l  and  A. 2)  .  Advisor  Number  (AD*JNUM)  and  Topic 
Number  (TOPNlfi)  were  identified  as  key  attributes.  Final 
output  report  requirements  were  also  determined  (see 
Printouts  B.I5  to  B.18  for  representative  examples).  Since 
two  user  views  (advisor  and  topic)  were  specified,  a  data 
model  was  developed  for  each  view.  Normalization  was 
attempted;  however,  the  structure  of  the  output  reports  and 
the  requirement  to  keep  data  entry  and  modification  simple 
precluded  normalization  beyond  first  normal  form. 

Integration.  Since  two  data  models  resulted  from 
the  previous  step,  integration  of  these  models  was  required. 


During  integration,  common  data  elements  between  the  two 
models  were  identified  and  inconsistencies  resolved.  Common 
data  elements  included  last  name,  first  name,  rank,  office 
symbol,  and  phone  number.  Storing  this  data  in  the  advisor 
data  model  would  reduce  data  redundancy  and  inconsistencies 
substantially;  however,  not  all  information  sources  in  the 
topic  data  model  are  advisors.  This  problem  was  resolved 
through  the  STATUS  data  element.  All  qualified  advisors, 
adjunct  readers,  interns,  committee  members,  and  those 
pending  classification  would  be  coded  with  an  alphabetic 
code  <Q,  A,  I,  C,  or  P> ;  whereas,  'non-advisors"  would  be 
left  blank.  The  topic  data  model  would  access  advisor  data 
through  the  advisor  number  stored  in  FAC1 ,  FAC2,  FAC3, 

BACK1 ,  BACK2,  EXP1 ,  and  EXP2  data  elements.  Multiple  query 
commands  are  required  to  reload  the  data;  however,  these  are 
simply  executed  through  a  command  file  (see  Printout  B.14). 
The  topic  data  model  accesses  a  third  relation  storing 
keyword  data  in  a  similiar  fashion. 

Schema  Devel opment .  Schema  development  forms  the 
transition  between  logical  and  physical  database  design. 
During  schema  development,  the  conceptual  schema  is 
translated  into  DBMS  constructs.  This  is  a  straightforward 
process  using  a  relational  database,  since  the  basic 
construct  is  a  relation  or  table  and  no  special  mapping  is 
required.  The  data  elements  simply  translate  into 


attributes,  and  the  two  models  are  defined  as  relations  in 
the  database. 

Physi cal  Database  Design.  Physical  database  design  is 
concerned  with  physically  storing  and  accessing  the 
database.  Physical  database  design  consists  of  data 
representation,  selection  of  database  entry  points  and 
access  paths,  and  allocation  of  data  to  storage  devices. 
Selection  of  access  paths  is  DBMS  dependent  and  Rrbase 
requires  an  indexed  sequential  access  method  (ISAM).  Also 
since  the  project  was  done  on  a  microcomputer  system, 
allocation  to  multiple  storage  devices  was  not  possible. 
The  system  is  resident  on  the  hard  disk  drive  with  back-up 
copies  maintained  on  floppy  diskettes. 

Data  Representat i on .  The  data  specifications 
defined  during  requirements  analysis  were  translated  into 
physical  terms  using  the  R:base  data  definition  language 
described  in  the  R:base  Series  6000  Relational  Database 


IV.  Conclusions  and  Recommendations 


Summary 

The  intent  of  this  thesis  was  to  evaluate  the 
feasibility  of  implementing  a  computerized  database 
management  system  to  support  the  AFIT  thesis  process.  The 
previous  chapters  have  demonstrated  that  the  thesis  process 
can  be  supported  by  a  microcomputer-based  relational 
database  management  system. 

Cone  1  us i ons 

A  relational  database  management  system  would  assist  the 
thesis  process  in  a  number  of  ways.  The  database  would 
reduce  redundancy  and  data  inconsistencies.  The  database 
would  optimize  control  and  data  management  through 
standardization  and  data  entry  restricted  by  password.  The 
database  would  increase  flexibility  by  responding  to  the 
changing  needs  of  varied  users.  The  system  is  especially 
suited  to  ad  hoc  reports.  The  database  would  be  easy  to  use 
with  a  limited  amount  of  training  since  data  is 
realistically  represented  in  tables  and  data  entry, 
retrieval,  and  manipulation  is  user  oriented  through  simple 
query  commands.  The  database  would  speed  access  with  nearly 


instantaneous  data  retrieval 


The  only  major  restriction  to 


the  system  is  the  limited  storage  ability  o-f  a 
microcomputer-based  system. 

Recommendat i ons 

It  is  recommended  that  LSH  -fully  implement  this  database 
system.  Although  this  project  -focused  only  on  integrating 
thesis  topics  and  advisors,  this  database  system  would  be 
useful  for  other  thesis  administrative  and  supervisory 
functions,  for  example,  monitoring  the  selection  of  current 
graduate  theses  research  topics  and  adv i sors/commi t tee 
members,  controlling  the  use  of  surveys/questionnaires,  and, 
finally,  supervising  the  review,  publication,  and 
distribution  of  completed  theses. 
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Appendix  A 

Personal  Data  Sheet 


Tel  if. 
Room: 
Bldg: 
Symool : 


213 
6*.  1 
LS? 


Name  &  Rank:  Joel  E.  Adkins,  Major,  USAF 

Academic  Rank/ 

Job  Title:  Assistant  Professor  of  Production  Management 

Education 


1971  MS,  Industrial  Management,  University  of  North  Dakota, 

Independent  Research  Paper 

1966  BBA,  Industrial  Management,  University  of  New  Mexico 

Relevant  Experience 


1983  -  Present:  Assistant  Professor,  Department  of  Contracting  Management, 
AFIT,  Wright-Patterson  AFB  OH,  Course  Director  for  PPM 
309,  Introduction  to  Systems  Production  Management; 

PPM  501,  Planning  for  Systems  Production;  and  PPM  502, 
Producibility 

1980  -  1983:  Instructor,  Department  of  Contracting  Management,  AFIT, 

Wright-Patterson  AFB  OH,  Course  Director  for  PPM  309, 
Introduction  to  Systems  Production  Management;  PPM 
501,  Planning  for  Systems  Production;  and  PPM  502, 
Producibility 

1976  -  1980:  Strategic  Systems  SPO,  Wright-Patterson  AFB  OH,  Chief  of 

Government  Furnished  Property  Management  Division  and 
Chief,  Missile  Manufacturing  Branch 


1975  -  1976:  AFIT  Education  with  Industry,  Lockheed  Missiles  and  Space 

Company,  Sunnyvale  CA 

1971  -  1975:  Space  and  Missile  Test  Center,  Vandenberg  AFB  CA,  Programs 

Planning  Manager 


Professional  Activity 


Publications : 

None 

Profess ional 

Societies : 

Member , 

National  Contract  Management  Association 

Member , 

Air  ?orcc  Association 

S r at omen t  of  Research  Int-Tcst 


Research  interests  include  manufacturing  productivity  analysis,  indus¬ 
trial  modernization,  and  m.muf ac tori ng  technology  development  and  implemen¬ 
tation  for  major  systems  within  the  Department  of  Defense. 
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LIST  OF  QUALIFIED  THESIS 

ADVISORS  (Q),  ADJUNCT 

READERS  (A), 

INTERNS  (I),  OR 

COMMITTEE, MEMBERS  (C) 

NAME 

STATUS 

OFFICE 

SYMBOL 

ADKINS,  Maj  Joel 

0 

ASD 

ALLEN,  Dr.  Robert  F. 

0 

ENS 

ANNESSER,  Lt  Col  Janes 

0 

LSMA 

ASKREN,  Dr.  William  B. 

A 

AFHRL 

8ARIARZ,  Maj  Anthony  S. 

0 

LSM 

BARNES,  Mr.  Warren  S. 

0 

LSM 

BATES,  Mr.  Michael  0. 

i 

c 

LSY 

BECK,  Maj  Charles  E. 

0 

LSH 

BENOIT,  Mr.  Donald  G. 

1 

LSP 

BLAZER,  nouglas  J» 

A 

AFLMC/LGSP 
Gunter  AFS 

BLOIIIN,  Capt  George  K. 

0 

DET 

BOWLIN,  Maj  William  F. 

I 

LSO 

BOWMAN ,  Maj  Thomas  L. 

I 

LSY 

BRESNAMAN,  Mr.  Patrick.  M. 

0 

LSMA 

RHODE,  Capt  Michael  J. 

0 

LSM 

BTLER,  Maj  Rodney 

0  •. 

LSM 

CAIN ,  Dr,  Joseph  P. 

Q  '  • 

ENS 

CAMPBELL,  Mr.  Dennis  E. 

0 

LSMA 

CAMPBELL,  Capt  John  A. 

0 

LSP 

CATHCART,  LCDR  George  R. 

I 

LSO 

CLARK,  Lt  Col  Charles  T. 

0 

LSM 
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THESIS  RESEARCH  TOPIC  PROPOSAL 
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A~*  Maj  Alan  E  M  Tucker 

or*c«  iMTCNesrea  t*cultv 


LS  Assc  For  Academic  Affai 
Rm  3 2U,  Side  <S&1 _ 


«QM«IMC,  TIT  LI 

Evaluation  of  Effect  of  Bare-base  Layout  Patterns  on  Base  Survivability 
lT*rc«tNT  ~  eaoait* 

Several  recenc  speakers  in  the  contingency  area  have  noted  that  current 
ba're-base  layout  ,  plans  call  for  the  "tent  cities"  to  be  organized  in 
neat,  predictable  patterns.  Many  people  are  beginning  to  question  the 
wisdom  of  these  procedures  in  tenns  of  their  impact  on  base  survivability. 
Assuming  there  is  no  natural  cover  (SW  Asia),  what  is  the  optimum  set  up 
of  tents  in  an  open  area?  Air  and  ground  attacks  should  be  considered 
along  wich  fire  and  expediency  of  construction. 


INPORMATIOM  SOURCES 

l*C«S«OUaO 

Contingency  Engineering  Management  Curriculum 
Air  Base  Survivability  Office 


Maj  Alan  Tucker 
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SCHOOL  OF  SYSTEMS  AMD  LOCISTICS  LS  Operating  Instruction  53-6 
Headquarters  Air  Force  Institute  of  Technology  (ATC)  15  October  1982 
Uright-Patterson  AFB  OH 


Schools 

Thesis  Advisors 

This  operating  instruction  describes  the  procedure  by  which  individuals,  both  faculty 
and  non-faculty,  participate  In  the  AFIT/LS  thesis  program.  It  describes 
the  qualifications  for  various  types  of  Involvement  and  establishes  the  respon¬ 
sibility  of  the  Craduate  Faculty  for  the  quality  of  thesis  research. 

THESIS  MANAGEMENT  PROGRAM 

Responsibility  for  the  management  of  the  thesis  program  and  for  the  individual  theses 
produced  by  AFIT/LS  graduate  students  Is  shared  by  the  graduate  faculty,  the  indivi¬ 
dual  thesis  advisor,  and  by  LSH  for  thesis  administration.  This  01  specifies  the 
qualifying  process  by  which  any  Interested  person,  whether  a  member  of  the  LS  faculty 
or  not,  can  become  a  Thesis  Advisor.  The  purpose  of  this  procedure  Is  to  make 
available  to  graduate  students  Che  largest  possible  number  of  qualified  thesis 
advisors.  The  general  policy  is  to  have  Individual  theses  although  exceptions  are 
allowed  as  determined  by  the  Thesis  Advisor  involved. 

1 .  The  Thesis  Advisor  and  Committee 


a.  Thesis  Advisors 

(1)  The  Thesis  Advisor  (fully  qualified)  has  primary  responsibility 
for  the  quality  of  Che  thesis  and  for  assigning  a  grade  to  the  thesis.  The  Advisor 
is  also  responsible  for  the  training  of  less  qualified  committee  members  and  for 
Informing  the  degree  candidate  of  the  administrative  requirements  and  schedules  of 
thesis  production.  The  fully  qualified  Advisor  signs  the  thesis  as  'Thesis  Advisor.' 

(2)  The  Thesis  Advisor  (Intern)  is  a  person  who  has  all  the  qualifi¬ 
cations  of  an  Advisor  except  that  he  or  she  has  not  yet  advised  an  AFIT  thesis.  The 
Advisor  (Intern)  must  have  a  fully  qualified  thesis  advisor  as  a  Reader  on  the  Thesis 
Committee  for  the  first  thesis  (or  group  of  theses)  advised  by  the  Intern.  The 
intern  performs  all  thesis  advising  functions  In  coordination  with  the  Reader. 

The  Advisor  (Intern)  signs  the  thesis  as  "Thesis  Advisor"  attesting  to  Its 
acceptability.  The  status  of  Thesis  Advisor  (Intern)  normally  applies  for  only  one 
class  year  providing  the  Reader  recommends  advancement  of  the  Intern  to  fully 
qualified  Advisor. 


OPR:  AFIT/LS  (Curriculum  and  Degree  Requirements  Committee) 
Distribution:  Each  Department  and  AFIT/DAPE 
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(3)  A  Thesis  Advisor  (Adjuncc)  Is  a  fully  qualified  Advtsoi  who  Is 
not  a  member  of  the  AfIT  faculty  or  staff-  The  Thesis  Advisor  (Adjunct)  performs  all 
thesis  advising  functions  In  coordination  with  a  Reader  and  signs  the  thesis  as 
"Thesis  Advisor"  attesting  to  Its  acceptability. 

b-  Thfe  Thesis  Committee  may  have  two  types  of  members.  The  Thesis 
Reader  and  the  Thesis  Committee  Member.  A  Thesis  Advisor  fully  qualified  is 
not  required  to  have  a  committee. 

(1)  A  Thesis  Reader  Is  a  Thesis  Advisor  (fully  qualified)  who  assists  a 
Thesis  Advisor  (Intern  or  Adjunct)  as  a  member  of  the  Thesis  Committee.  The  respon¬ 
sibility  of  the  Reader  varies  with  the  requirements  of  the  Advisor.  The  Reader  will 
help  a  new  Advisor  learn  the  administrative  and  academic  peculiarities  of  AFI7  thesis 
advising.  The  Reader,  In  every  case,  also  attests  Co  che  acceptability  of  the 
thesis.  The  Reader  is  an  expert  who  assists  the  Advisor  In  whatever  way  is  needed. 

The  Reader  is  Involved  in  all  stages  of  che  thesis  production  process  including  the 
advancement  of  an  Advisor  (Intern)  to  fully  qualified  status. 

(2)  A  Thesis  Committee  Member  (other  than  a  Reader)  Is  a  person  not 
qualified  to  be  an  Advisor.  The  usual  purpose  of  serving  as  a  Committee  Member 
(other  than  Reader)  is  to  learn  how  to  advise  thesis  research  by  working  closely  with 
an  Advisor  and  a  student  through  a  thesis  production  effort.  Normally,  a  person 

who  has  served  on  two  thesis  committees  as  a  member,  and  has  at  least  a  Masters 
Degree,  will  qualify  to  serve  as  a  Thesis  Advisor  (Intern)  the  following  class  year. 


(3)  The  Advisor  may  add  to  the  Committee.  Member*  may  come  from  any 
job  assignment  and  will  usually  have  strong  expertise  or  interest  In  the  thesis 
subject . 

2 .  Qualifications  for  Thesis  Program  Participation 

a .  Title  Quail f Icat ions 


Thesis  Advisor 
(fully  qualified) 


Thesis  Advisor 
( Intern) 


AFIT  faculty  or  staff  member  who,  within 
the  past  three  class  years,  has  served 
successfully  as  a  (fully  qualified)  Thesis 
Advisor;  Thesis  Advisor  (Intern),  or 
Reader,  as  defined  In  this  01,  or  who 
have  otherwise  been  determined  qualified 
by  the  faculty. 

ATIT  faculty  or  staff  member  who  has 
either;  (a)  a  Masters  degree  or  higher 
with  completion  of  a  formal  research 
requirement  (Thesis  or  Dissertation);  or 
( b)  favorable  recommendation  from  the 
Thesis  Advlsor(s)  of  two  theses  for 
which  the  member  has  served  as  a 
Committee  Member. 
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Non-AFIT  Individual  with  a  Masters 
degree  or  higher  with  a  formal  research 
requirement  (Dissertation  or  Thesis) 
who  has  been  accepted  by  the  faculty  for 
this  role. 

AFIT  faculty  or  staff  member,  serving  as 
a  thesis  committee  member,  who  is  a 
fully  qualified  Thesis  Advisor  as 
defined  in  this  01. 

Any  person  with  at  least  a  Masters 
degree  and  an  expressed  Interest  in  .the 
thesis  research. 

ar 

b.  Approval .  Anyone  Interested  in  becoming  a  Thesis  Advisor  or  Thesis 
Committee  Member  should  submit  a  personal  data  sheet  (Atch  1)  to  the  LS  Graduate 
Qualifications  and  Recruitment  Committee  (GQRC).  The  CQRC  will  evaluate  applications 
and  recommend  approval  or  disapproval  to  the  Graduate  Faculty,  with  whom  final 
authority  resides.  Anyone  who  does  not  meet  the  specific  qualifications  of  this  01 
but  who  is  considered  qualified  by  the  CQRC  may  be  recommended  by  the  GQRC  to  the 
Craduate  Faculty  for  approval  in  any  thesis  management  position.  If  approved  by  the 
Graduate  Faculty,  LSH  will  place  the  name  and  data  sheet  In  the  published  list  of 
vallable  thesis  advisors  and  committee  members. 

3.  Operation 

a.  Thesis  Quality.  The  Advisor  has  primary  responsibility  for  the  quality 
of  the  thesis-  The  quality  of  the  overall  thesis  program  (content,  student 
achievement,  and  advisor  performance)  is  the  responsibility  of  the  Craduate  Faculty. 

The  Craduate  Academic  Standards  Committee  and  the  Craduate  Curriculum  Committee  will 
establish  review  procedures  to  determine  whether  the  desired  level  of  quality  is 
being  achieved. 

b.  Time  Limits.  Approval  as  Thesis  Advisor  will  be  Indefinite 
provided  at  least  one  thesis  Is  advised  during  the  past  three  class  years. 

Departure  from  UPAFB  duty  assignment,  or  request  for  removal  by  the  Individual 
concerned,  will  cause  removal  from  the  approved  Advisor  list. 

c.  Oral  Defense.  An  oral  defense  of  the  thesis  by  the  degree  candidate, 
attended  by  the  thesis  committee  and  ocher  persons  who  may  be  invited.  Is  encouraged 
but  Is  not  mandatory. 

d.  Implementat ion .  The  approved  Advisors  and  Committee  Members  list  pub¬ 
lished  annually  by  LSI!  1  October  will  be  the  official  list  of  potential  participants  In 
the  thesis  program  for  the  then  current  class. 


Thesis  Advisor 
(Adjunct) 


Reader 


Committee  Member 
(other  than  Reader) 
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e.  Administration  and  Training.  LSH  will  administer  the  thesis  program, 
tn  addition,  LSH  will  periodically  present  workshops  In  thesis  advising  to  Include  at 
least  one  annual  training  session  In  procedural  detail  for  all  Advisors.  LSH  will 
also  maintain  and  make  available  name  lists  and  the  data  sheets  fo.  everyone 
qualified  for  thesis  management  positions,  Including  the  theses  with  which  they  have 
been  Involved,  and  other  such  records  deemed  necessary  by  LSH  or  the  Graduate  Faculty. 


1  Atch 

Sample  Personal  Data  Sheet 
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Tel  9;  5-1111 

Room:  432 

Bide:  641 

Symbol : 


Name  &  Hank : 

Academic  Rank/ 
Job  Title: 

Education 


Howard  Neff,  Captain,  USAF 


Associate  Professor  of  Logistics  Management 


1975  PhD,  Industrial  4  Organizational  Psychology,  Purdue  University; 

Dissertation  Title:  X&T  Y  Management  Theories  as  They  Relate 
to  Job  Satisfaction 

1972  MS,  Human  Factors  Engineering,  Purdue  University;  No  thesis 

1971  BA,  Psychology,  East  Virginia  University 

Relevant  Experience 

1978-80  Instructor,  Department  of  Psychology  and  Leadership,  USMA 
Courses  Taught:  Introduction  to  Psychology 
Management  Leadership  '• 

1975-78  Chief,  Job  Evaluation  and  Organization  Center,  USN  Human 
Resources  Laboratory 

Professional  Activity 

Publications;  "Why  Worry  About  Job  Satisfaction?"  Defense  Svstem 
Management  Review,  Summer  1979 

"Technology  Transfer",  Proreed  Inge  of  the  10th  Annual 
Workshop  on  Log  1st les  Psychol ocv 


Professional 

Societies: 


Member,  American  Psychologin.il  Association 
Chairman,  Midwestern  Psychological  Association 
Member,  Rocky  Mountain  Psychological  Association 


Statement  of  Research  Interest 

Research  Interests  Include  organizational  diagnosis,  organizational 
development,  organ  l  z.at  ion  behavior,  job  satisfaction,  organ  izat  iona  1  climate, 
leadership  style  and  its  relation  to  organizational  performance,  and 
organizational  stress  and  its  relation  to  baldness. 


0 


LiU I  53-d  Attacnrent  2  15  October  19c l 


SAMPU 


Tel  *:  5—3553 

Reo.n:  10 1 

a  L  J  5 :  33 

S  '-  noc  l : 


Na.-.e  4  Crade: 

Acadsaic  Rank/ 
Job  Tide: 


Loni  Lee  Pouisen,  CS-12 

Chief.  Research  4  Consul  cat  ion ,  0L3AM 


EduC3Cion 


1919  Nonresident  National  Security  Defense  Course 
1916  MS.  Logistics  Management,  AFIT;  Thesis  Title:  "Tears 
Theor--" 

1972  BA,  EngLish  Literature,  Purdue  University 


Re  levant  Experience 


1979-Present 
1976-79 
19  74-75 

1971-74 


Chief,  Research  6  Consultation.  DISAM.  VTPAF3 
Deputy  Director,  Research  &  Consultation,  DISAM.  VPAF3 
Assistant  Professor,  Defense  Institute  of  Security 
Assistance  Management,  WPAFB 
Director,  Accounting  Division,  Any  Supply  Center, 
Barstow 


Prrressionjl  Ac  t  i  v  i  t  y 


Pub l icat ions :  "The  Acquisition  of  Minor  Systems,"  Jouna t  of 

Log i sties.  Su-.-.er.  19  79 

"Old  Bottles,  New  Vine,"  "Legist ics  Save  t  run. 
Spring,  1978 


P  apers : 


Plus  14  additional  erciuLes,  1973-78,  on  Logistics  Management 
"Language  and  Logistics,’’  22nd  ITCC,  St.  Paul,  MN,  1973 


Profess  i-'n.i  l 
S.v  le  C  ie  s : 


Me_her.  Oita  Pr-cessing  Management  Association 
Me.cte  r .  Society  of  Logistics  Engineers 

Cnjirun.  Logistic*  Management  Assoc  i  jc  ion.  DntJn  Chapter 


St  it  -■tent  of  Research  Intere  sc 

My  areas  of  research  inceresc  include  contracting  and  con t net  (construct  ton) 
management.  mana;e-ent  cybernetics,  Minorit  ■  Business  subcontracting  ind 
overhead  nomtjrship. 


'.ore  tr.ac  if  v.iu  ■.•■.e  n-.-tr  ui  .'nolle  it  i  .-ns  or  r  i.'irs,  1  i  >c  nl-  most  recent  mJ 
re  re  l  v  indi-jte  ipcr’priite  ”.;-Vr  in.)  c.\  i.  ir.-i  r-.  ■*.: ;  ndu  r  -  THIS  DATA  SHEET 
SH'.ULD  3E  O'-c  ?  '  IE  '0.(_Y- 
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FROM:  AFIT/ISH  TO  August  1984 

SUBJECT:  Thesis  Research  Topic  Proposals 
TO:  Thesis  Advisors  (All  Classifications) 

1.  I  am  in  the  process  of  bringing  our  book  of  Thesis  Research  Topic 
Proposals  to  date  for  use  by  the  current  class.  Dated  proposals  will  be 
removed,  some  existing  proposals  will  probably  need  modification,  and 
new  ones  will  be  added  to  suggest  your  new  ideas. 

2.  While  some  students  develop  ideas  for  their  research  from  their  own 
experience,  this  book  is  a  shopping  list  which  most  students  review  for 
suggestions  and  idea  starters.  Some  projects  are  taken  essentially  as 
proposed  and  some  are  modified  and  refocused  through  discussion  with  the 
faculty  members  who  suggested  them  or  are  listed  as  the  faculty  contacts. 

3.  Because  there  are  so  many  students,  we  must  all  do  our  part  in  providing 
suggestions  for  research  in  our  areas  and  in  acting  as  thesis  advisors  or 
readers.  As  professionals  in  our  fields,  we  all  have  ideas  about  suitable 
topics  for  student  theses.  If  we  don't  suggest  them,  the  students  will  have 
no  way  of  knowing  what  they  are.  And  if  you  don't  happen  to  have  the  stu¬ 
dents  in  class  during  the  summer-  or  fall  quarter,  they  probably  won't  hear 
about  your  suggestions  for  thesis  topics.  By  placing  all  such  suggestions 
in  several  notebooks  in  the  library,  we  make  them  available  for  the  students 
to  review  at  their  convenience. 


4.  Please  prepare  a  form  for  each  proposed  research  topic.  A  sample  ard 
directions  for  completing  the  form  are  attached.  Your  secretaries  should 
have  copies  of  the  Thesis  Research  Topic  Proposal  form.  If  they  run  out, 
they  can  get  additional  forms  from  tSH.  If  you've  already  submitted 
one--submit  a  couple  more. 

5.  Old  Hands 

I  attach  all  proposals  from  last  year's  book  for  which  you  are  listed 
as  the  faculty  contact--these  may  be  proposals  that  you  originated  or  they 
may  have  been  originated  by  others.  Please  review  them  to  determine  whether 
they  are  still  useable  topics. 

For  each  that  is  still  OK  as  is--indicate  this  right  on  the  form. 

For  each  that  is  no  longer  useable--indicate  this  right  on  the  form. 

For  each  that  needs  revision--prepare  a  new  proposal  form  and 
attach  it  to  the  old  one  so  I’ll  know  what  has  been  supplanted. 

For  any  new  proposals  that  you  may  have--prepare  a  form. 

Then  return  all  topics  (old,  new,  or  revised)  to  LSH. 


6.  I'd  like  to  have  the  new  and  revised  topics  available  for  the  students 
to  consider  as  soon  as  possible.  The  sooner  we  present  your  ideas  to  the 
students,  the  more  likely  it  is  that  they  will  be  selected  for  thesis  research. 


TERRANCE  M.  SKELTON 
Dept  of  Communication 
and  Research  Methods 
School  of  Systems  and  Logistics 


3  Atch 

1 .  Proposal  Form 

2.  Directions 

3.  Sample 


DIRECTIONS 


1.  Enter  the  general  category  number  In  pencil.  We'll  put  all  proposals  in 
a  given  category  in  sequence  and  assign  sequential  numbers.  The  category 
numbers  are  as  follows: 

1.  Civil  Engineering 

2.  Contracts 

3.  Cost  Estimation  {Acquisition,  Logistics,  and  Procurement) 

4.  Distribution 

5.  Economic  Analyses 

6.  Energy /Environment/Safety 

7.  Human  Resources/Organizational  Behavior 

8.  International  Logistics 

9.  Maintenance 

10.  Management  Information  Systems/Decision  Support  Systems 

11.  Manufacturing 

12.  Resource/Financial  Management 

13.  Space  Systems 

14.  Supply/Inventory  Requirements  ^ 

15.  Systems  Acquisition 

16.  Transportation 

17.  Other  Management  Topics 

Please  place  the  appropriate  category  nmber  (lightly  in  pencil!)  in  the 
upper  left-hand  box  (Shopping  List  Number).  If  a  given  proposal  should 
appear  in  more  than  one  of  the  sections  of  the  book,  place  more  than  one 
number  in  the  box.  Thus,  students  searching  the  book  will  find  the  proposal 
when  searching  the  category  (or  categories)  in  which  it  is  placeo.  (Don't 
go  hog  wild  on  this  or  we'll  defeat  the  purpose  of  the  categorization.) 

2.  Your  name. 

3.  Your  department  symbol. 

4.  If  you  know  of  other  faculty  who  may  be  interested  in  this  topic,  list 
them  (check  with  them  first).  Thus,  if  you  have  already  accepted  a  full 
load  of  projects.  Interested  students  will  know  who  else  will  be  willing 
to  act  as  advisor. 

5.  Keep  this  brief--just  enough  words  to  identify  the  project. 

6.  Describe  the  project  as  best  you  can  in  150-250  words.  You  don't  have 
room  for  close  detail,  but  you  can  give  the  reader  an  idea  of  what  the 
project  is  concerned  with.  Interested  students  will  come  to  see  you  for 
further  explanation  and  discussion.  You  might  include  a  brief  statement 
of  the  condition  giving  rise  to  the  problem  and  indicate  the  specific 
problem  to  be  addressed  and  the  questions  to  be  answered.  Continue  on  a 
second  page  if  absolutely  necessary. 

7.  List  people  (with  organizational  symbols  and  telephone  numbers)  who  may 
provide  background  information  or  particular  documents  or  other 
published  information  to  be  checked  for  background  information. 

8.  list  possible  or  probable  primary  sources  from  which  data  might  be 
collected  in  the  course  of  the  project. 

9.  List  individuals  (with  organi zational  symbols  and  telephone  numbers)  or 
organi zations  that  arc  specialists  in  all  or  part  of  the  area  concerned 
and  might  be  contacted  in  the  course  of  the  project. 


THESIS  RESEARCH  TCP'C  ? RC3OSAL 


ITATlxlnT  3* 

O 


All  boxes  will  not  necessarily  be  completed  on  all  tonic  orooosals, 
but  most  should  be  applicable  to  most  oroposals. 


(MFO«u>nON  SOURCES 

|*CVS"OgNO 

o  - 

JAT* 

o 

’X»1*-<SC 

o 

AfiT  'c*“ 

AT 


VO«KIN<;  TITLC 

Development  of  cargo  generation  forecast  models  for  CONUS  MAC  aerial  ports  of 
embarkation. 


STATCMCNT  o * 

Historically,  cargo  generation  at  our  aerial  ports  of  embarkation  (APOEs)  rougnly 
follows  a  seven-day  cycle  with  Sunday  and  Monday  being  low  generation  days,  several 
modern  time  series  analysis  techniques  have  been  applied  to  historical  ciata  to  aerive 
a  forecasting  model.  These  historical  models  have  been  only  partially  successful  due 
to  the  high  degree  of  randomness  in  the  data  (because  of  real-world  situations).  Pre¬ 
liminary  exploration  of  real-time  data  to  complement  the  historical  model  is  under  way. 
Once  a  reliable  forecast  method  is  in  being,  the  schedulers  can  better  plan  in  advance 
for  cargo  generation.  This  will  allow  scheduled  airplane  departure  to  be  closer  to 
to  cargo  arrival  at  the  port,  which  reduces  aerial  port  hold  time  and  MAC  pipeline 
possession  time.  While  the  primary  purpose  for  developing  a  reliable  cargo  generation 
forecasting  capability  is  to  reduce  cargo  pipeline  time,  a  significant  by-product  would  | 
be  less  aircrew  scheduling  turbulence,  thereby  contributing  to  the  aircrew  enhancement 
program. 

The  problem,  then,  is  to  determine  a  reliable  way  to  forecast  cargo  generation  (arrival) 
at  the  CONUS  MAC  APOEs  at  least  48  hours  prior  to  actual  generation. 


IN  formation  sources 

8*C AGROUND 

HQ  MAC/TRQS/Capt  Bonnell/AV 
Scott  AFB,  It  62225 

638-2680 

Historical  cargo  transportation  data  is  in  the  Hg  MAC  data  base.  It  can  be  retrieved 
and  formatted  by  inquesting  techniques.  Real-time  data  is  resident  in  user-ori ented 
data  bases  throughout  the  CONUS.  Hg  MAT/TRQS  is  currently  exploring  the  content  and 
availability  of  these  data  bases. 


EK»t«TI»t 

Same  as  background  source. 


Table  A.l 


Thesis  Advisor  Data  Elements 


Data  Attribute 


* 

El  emen  t 

Name 

Type 

Length 

1 

Advisor  Number 

ADUNUM 

TEXT 

4 

characters 

2 

Status 

STATUS 

TEXT 

1 

char ac  ters 

3 

Phone  Number 

PHONE 

TEXT 

8 

characters 

4 

Room 

ROOM 

TEXT 

4 

characters 

5 

Building 

BLDG 

TEXT 

4 

characters 

6 

0-f-fice  Symbol 

OFFSYM 

TEXT 

10 

characters 

7 

First  Name 

FNAME 

TEXT 

10 

charac  ters 

8 

Last  Name 

LNAME 

TEXT 

15 

characters 

9 

Rank 

RANK 

TEXT 

7 

characters 

10 

Job  Title 
Educat i on 

• 

• 

JOBTITLE 

TEXT 

65 

charac  ters 

1  1 

Date 

<1> 

EDDATE1 

TEXT 

2 

characters 

12 

Degree 

<1) 

DEGREE 1 

TEXT 

5 

characters 

13 

Maj  or 

<  1 ) 

MAJ0R1 

TEXT 

40 

characters 

14 

School 

(1) 

SCHOOL 1 

TEXT 

35 

charac  ters 

15 

The si s/Di 

sser  tat i on 

< 1 ) TH/DI  SI 

TEXT 

1 

characters 

16 

Commen  ts 

<1) 

EDTEXT1 

TEXT 

50 

characters 

17 

Date 

<  2) 

EDDATE2 

TEXT 

2 

characters 

18 

Degree 

(2) 

DEGREE2 

TEXT 

5 

characters 

19 

Maj  or 

<  2) 

MAJ0R2 

TEXT 

40 

characters 

20 

School 

<  2) 

SCH00L2 

TEXT 

35 

characters 

21 

Thes i s/D i 

sser  tat i on 

<2>TH/DIS2 

TEXT 

1 

characters 

22 

Comments 

(2) 

EDTEXT2 

TEXT 

50 

characters 

23 

Date 

(3) 

EDDATE3 

TEXT 

2 

characters 

24 

Degree 

(3) 

DEGREE3 

TEXT 

5 

charac  ters 

25 

Maj  or 

<  3) 

MAJ0R3 

TEXT 

40 

charac  ters 

26 

School 

<  3) 

SCH00L3 

TEXT 

35 

characters 

27 

Thes i s/D i sser  tat i on 

<  3>TH/DI S3 

TEXT 

1 

charac  ters 

28 

Comments 
Re  levant 

<  3) 

Exper i ence 

EDTEXT3 

• 

• 

TEXT 

50 

characters 

29 

Date 

<  1 ) 

EXPDATE1 

TEXT 

5 

characters 

30 

Comments 

<  1 ) 

EXPTEXT1 

TEXT 

65 

characters 

31 

Date 

<  2) 

EXPDATE2 

TEXT 

5 

characters 

32 

Comments 

<  2) 

EX  PT  EXT  2 

TEXT 

65 

charac  ters 

33 

Date 

<  3) 

EXPDATE3 

TEXT 

5 

charac  ters 

34 

Comments 

<  3) 

EX  PT  EXT  3 

TEXT 

65 

characters 

35 

Date 

<  4) 

EXPDATE4 

TEXT 

5 

characters 

36 

Comments 

<  4) 

EXPTEXT  4 

TEXT 

65 

characters 

37 

Date 

(5) 

EXPDATE5 

TEXT 

5 

characters 

38 

Commen  ts 

<  5) 

EXPTEXT  5 

TEXT 

65 

charac  ters 

Key 

Y 


Continued  on  next  page 


Table  A.l  <  Con  t  i  nuc 
Thesis  Advisor  Data  Elements 


# 

Data 

El  emen  t 

Attr i bute 

Name  Type 

Length 

39 

Pro-f  essi  onal 
Publ i cat i on 

Ac  t i v i t y 
<1> 

a 

PUB1 

TEXT 

158 

characters 

40 

Publ i cat i on 

(2) 

PUB2 

TEXT 

158 

characters 

41 

Pos i t i on 

<1> 

P0SIT1 

TEXT 

10 

characters 

42 

Organ i zat i on 

<1 ) 

0RGNAME1 

TEXT 

30 

characters 

43 

Posi t i on 

<  2) 

P0SIT2 

TEXT 

10 

characters 

44 

Organ i zat i on 

<  2) 

0RGNAME2 

TEXT 

30 

charac  ters 

45 

Research  Interest: 
Area  (1) 

AREA1 

TEXT 

50 

characters 

46 

Area  <2> 

AREA2 

TEXT 

50 

char acters 

47 

Area  (3) 

AREA3 

TEXT 

50 

characters 

Table  A. 2 


Thesis  Topic  Data  Elements 


Data  Attribute 

#  Element  Name  Type  Length  Key 


1 

Topic  Number 

TOPNUM 

TEXT 

4 

characters 

2 

Category  Number 

CATNUM 

TEXT 

2 

charac  ters 

3 

Sequence  Number 
Faculty  Contacts: 

SEQNUM 

TEXT 

3 

characters 

4 

Adv i sor  Number  < 1 ) 

FAC1 

TEXT 

4 

characters 

5 

Last  Name  (1) 

F1LNAME 

TEXT 

15 

characters 

6 

First  Name  <1> 

F1FNAME 

TEXT 

10 

characters 

7 

Rank  <1) 

FI  RANK 

TEXT 

7 

characters 

8 

Office  Symbol  <1> 

F10FFSYM 

TEXT 

10 

characters 

9 

Advisor  Number  (2) 

FAC2 

TEXT 

4 

characters 

10 

Last  Name  <2> 

F2LNAME 

TEXT 

15 

characters 

11 

First  Name  <2) 

F2FNAME 

TEXT 

10 

characters 

12 

Rank  <  2) 

F2RANK 

TEXT 

7 

characters 

13 

Office  Symbol  <2> 

F20FFSYM 

TEXT 

10 

characters 

14 

Advisor  Number  <3) 

FAC  3 

TEXT 

4 

characters 

15 

Last  Name  <3) 

F3LNAME 

TEXT 

15 

characters 

16 

First  Name  <3) 

F3FNAME 

TEXT 

10 

characters 

17 

Rank  <  3) 

F3RANK 

TEXT 

7 

char acters 

18 

Office  Symbol  <3> 

F30FFSYM 

TEXT 

10 

characters 

19 

Title 

TITLE 

TEXT 

70 

characters 

20 

Statement  of  Problem 
Information  Sources: 
Background: 

ABSTRACT 

TEXT 

790 

characters 

21 

Advisor  Number  <1> 

BACK1 

TEXT 

4 

characters 

22 

Last  Name  (  1 ) 

B1LNAME 

TEXT 

15 

characters 

23 

First  Name  <l> 

BlFNttlE 

TEXT 

10 

characters 

24 

Rank  <  1 ) 

B1  RANK 

TEXT 

7 

characters 

25 

Office  Symbol  <1> 

B10FFSYM 

TEXT 

10 

characters 

26 

Phone  Number  < 1 ) 

B IPHONE 

TEXT 

8 

characters 

27 

Advisor  Number  <2) 

BACK2 

TEXT 

4 

characters 

28 

Last  Name  <2) 

B2LNAME 

TEXT 

15 

characters 

29 

First  Name  <2> 

B2FNAME 

TEXT 

10 

characters 

30 

Rank  (2) 

B2RANK 

TEXT 

7 

characters 

31 

Office  Symbol  <2> 

B20FFSYM 

TEXT 

10 

charac  ters 

32 

Phone  Number  (2) 

Data: 

B2PH0NE 

TEXT 

8 

characters 

33 

Data 

TDATA 

TEXT 

158 

characters 

Continued  on  next  page 
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Table  A. 2  (Continued) 


Thesis  Topic  Data  Elements 


It 

Data 

El  ement 

Attr i bute 

Name  Type 

Length 

34 

Exper  t i se : 
Advisor  Number 

<1> 

EXP1 

TEXT 

4 

characters 

35 

Last  Name 

<1) 

E1LNAME 

TEXT 

15 

characters 

36 

First  Name 

<1> 

El FNAME 

TEXT 

10 

characters 

37 

Rank 

<1> 

El  RANK 

TEXT 

7 

characters 

38 

Office  Symbol 

<  1  ) 

E10FFSYM 

TEXT 

10 

characters 

39 

Phone  Number 

<1> 

El  PHONE 

TEXT 

8 

characters 

40 

Advisor  Number 

<  2) 

EXP2 

TEXT 

4 

charac  ters 

41 

Last  Name 

<  2) 

E2LNAME 

TEXT 

15 

characters 

42 

First  Name 

<  2) 

E2FNAME 

TEXT 

10 

characters 

43 

Rank 

<  2) 

E2RANK 

TEXT 

7 

characters 

44 

Office  Symbol 

<2> 

E2QFFSYM 

TEXT 

10 

characters 

45 

Phone  Number 

(  2) 

E2PH0NE 

TEXT 

8 

charac  ters 

46 

Key  Number: 

Key  Number  < 1 ) 

KEY1 

TEXT 

2 

charac  ters 

47 

Key  Number  (2) 

KEY2 

TEXT 

2 

charac  ters 

48 

Key  Number  <3) 

KEY3 

TEXT 

2 

characters 

Key 


46 
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GUIDE  TO  THESIS  DATABASE  USING  R : BASE  SERIES  £000 


INTRODUCTION 

Rtbase  Series  £000  is  a  mu’ti-user  relational  database 
system  which  allows  the  user  to  enter,  manipulate,  and  store 
data.  This  guide  reviews  some  basic  operations  of  R:base 
especially  as  they  apply  to  the  THESIS  database.  It  assumes 
the  user  has  read  the  R:base  Series  £000  User  Manual  and 
accompanying  documents,  which  are  the  source  documents  -for 
this  guide.  It  assumes,  also,  that  the  user  is  familiar 
with  basic  B2S  operations.  A  list  of  R:base  commands  and 
their  proper  syntax  is  provided  in  Table  B.l. 


LOADING  AND  RUMMING  RiBASE 

After  you  sign  on  and  the  system  displays  the  COMMAND 
prompt,  type  R£K- [601  to  load  R:base.  The  system  will 
respond  with  a  large  graphic  R  indicating  Rtbase  is 
initializing.  LJhen  the  R>  prompt  is  displayed,  R:base  is 
operating  and  ready  to  accept  input. 

If  at  any  time  you  have  a  problem  in  Rtbase,  use  the 
HELP  command  to  receive  a  description  of  R:base  commands  and 
their  syntax.  For  assistance  when  entering  command 
information,  use  the  PROMPT  command  to  be  cued  for 
parameters  and  options  by  "fill  in  the  blank*  screens. 

To  access  a  previously  defined  database,  use  the  OPEN 
command  Ce.g.,  OPEN  THESIS).  The  system  will  open  the 
appropriate  database  files  and  respond  with  a  ’Database 
exists’  message.  If  the  OPEN  command  is  executed  while 
another  database  is  open,  R:base  will  close  that  database 
since  only  one  database  may  be  open  at  a  time. 


DEFINING  A  DATABASE 

The  R:base  data  dictionary  contains  definitions  of  a 
database's  attributes  and  relations,  rules  for  data 
validation,  and  passwords  to  restrict  access. 

The  DEFINE  command  is  used  to  initially  define  a 
database  or  to  subsequently  access  an  existing  database  to 
modify  its  structure.  Rtbase  will  search  through  database 
files  for  the  database  and  if  the  database  does  not  exist, 
will  create  one.  A  database  name  is  limited  to  seven 
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characters.  A  D>  prompt  will  be  displayed  indicating  R:base 
is  in  the  de-fine  module. 

I-f  you  wish  to  restrict  access  to  the  database  or 
relations  in  the  database,  a  database  password  is  required. 
To  spec  i-f  y  a  database  password  in  the  de-fine  module  use  the 
OWNER  command.  An  owner  password  may  also  be  modified  at 
any  time  by  the  RENAME  OWNER  command. 

The  ATTRIBUTES  command  defines  attributes  in  the 
database.  Attributes  are  specified  by  their  name,  type 
(DATE,  DOLLAR,  INTEGER,  REAL,  TEXT,  or  TIME),  length,  and 
whether  they  are  a  KEY.  An  attribute  name  is  limited  to 
eight  characters  and  cannot  contain  embedded  spaces. 

The  RELATION  command  defines  relations  in  the  database. 
A  relation  is  specified  by  its  name  and  the  list  of 
attributes  that  are  related  under  this  name. 

The  RULES  command  specifies  validation  rules  on  data  in 
addition  to  automatic  type  checks.  Data  values  are  checked 
during  data  entry  and  modification  either  against  some  data 
value  or  against  another  attribute.  To  display  the  rules 
which  apply  to  a  database,  type  SHOW  RULES  [RETURN].  Rules 
for  the  THESIS  database  are  listed  in  Printout  B.l. 

You  may  also  restrict  access  to  the  database  at  the 
relational  level.  The  PASSWORDS  command  specifies  read 
(RPW)  and/or  modify  <MPW>  passwords  for  any  relation  in  the 
database.  A  password  is  limited  to  eight  characters.  The 
default  password  is  NONE,  which  allows  anyone  to  read  or 
modify  a  relation.  The  USER  command  identifies  your 
password  to  R:base. 

An  example  of  a  database  definition  is  shown  in 
Printout  B.2.  The  attributes  currently  specified  for  the 
relations  ADVISOR,  ARESS ,  CATLIST,  KEYLIST,  STLIST,  and 
TOPIC  are  listed  in  Printouts  B.3  to  B.9.  Listings  of 
CATLIST,  KEYLIST,  and  STLIST  may  also  be  found  in  Printouts 
B. 10  to  B. 12. 


ENTERING  DATA 

The  LISTREL  command  displays  a  list  of  all  defined 
relations  in  the  database.  The  LISTATT  command  displays  a 
list  of  all  defined  attributes  and  their  associated 
relations. 

R:base  provides  a  number  of  data  entry  options  using  the 
LOAD  and  ENTER  commands.  LOAD  WITH  PROMPTS  uses  the 


attribute  name  and  data  type  as  a  prompt  -for  each  attribute 
to  be  loaded.  This  method  is  recommended  for  initial  data 
entry.  The  ENTER  command  is  used  with  R:base  forms.  Refer 
to  Section  3  of  the  R:base  user  manual  for  a  description  on 
how  to  create  forms  or  use  the  HELP  FORMS  command. 


EDITING  DATA 

The  CHANGE,  ASSIGN,  and  EDIT  commands  change  an 
individual  value,  several  values,  or  all  values  in  a 
relation.  The  EDIT  command  may  also  use  a  previously 
created  form.  You  may  use  ADV.FM1,  ADV.FM2,  and  ADV.FM3  to 
edit  the  ADMISOR  relation,  and  T0P.FM1  to  edit  the  TOPIC 
relation.  The  DELETE  command  deletes  specific  or  duplicate 
rows  from  a  relation.  Data  modification  commands  are 
limited  to  users  who  have  permission  to  modify  a  particular 
relation. 


MANIPULATING  DATA 

Using  R:base  commands,  you  may  manipulate  data  stored  in 
the  database  to  meet  your  specific  needs.  Rows  and  columns 
from  any  relation  can  be  displayed  on  the  terminal,  printed 
by  the  printer,  or  stored  on  disk  in  an  ASCII  file. 

The  SELECT  command  displays  attributes  from  any  relation 
in  the  database.  The  screen  will  display  as  much  of  each 
row  as  can  fit  on  the  screen.  A  SORTED  BY  clause  specifies 
up  to  ten  attributes  for  sorting.  A  WHERE  clause  specifies 
conditions  for  each  output  row. 

The  PROJECT  command  creates  a  new  relation  from  an 
existing  relation  by  selecting  attributes,  rows,  and  their 
sorted  order .  This  command  is  useful  for  reducing  the  size 
of  a  large  relation  when  only  a  subset  is  needed. 

The  JOIN  command  creates  a  new  relation  by  combining 
rows  from  two  other  relations.  The  rows  in  the  new  relation 
are  based  upon  the  comparison  of  an  attribute  from  each 
relation.  Attributes  must  have  the  same  data  type  to  be 
compared. 

The  UNION  command  is  used  to  combine  two  relations  or  to 
add  a  new  attribute  to  an  existing  relation. 

The  INTERSECT  command  forms  a  new  relation  containing 
the  rows  from  two  relations  that  have  common  matching 
attributes. 


The  SUBTRACT  command  is  the  opposite  of  the  INTERSECT 
command,  and  -forms  a  new  relation  composed  o-f  rows  -from  one 
relation  that  do  not  have  an  attribute  matching  a  second 
relation. 

I-f  an  application  consists  o-f  a  sequence  o-f  R:base 
commands,  you  may  write  the  commands  into  a  command  -file  and 
use  the  INPUT  command  to  execute  the  entire  sequence  as  i-f 
the  commands  were  entered  at  the  terminal.  RESEARCH. RPT  and 
TOPIC. RPT  are  examples  o-f  two  such  command  -files  (see 
Printouts  B.13  and  B.14). 

REPORTS 

The  R:base  report  writer  lets  you  create  a  report  using  one 
of  the  relations  in  the  database.  You  can  design  a  report 
with  headings  (titles),  detail  (body),  and  footings 
(summaries).  Data  may  be  used  from  selected  attributes  or 
computed  variables.  Output  may  be  directed  to  the  terminal, 
printer,  or  command  file  using  the  OUTPUT  command  and  viewed 
with  the  PRINT  command.  If  output  is  directed  to  the 
printer,  it  is  necessary  to  redirect  output  to  the  terminal 
before  printing  will  begin.  For  example: 

R>  OUTPUT  PRINTER  C RETURN! 

R>  PRINT  ARES. RPT  SORTED  BY  AREA  LNAME  C RETURN! 

R>  OUTPUT  TERMINAL  C RETURN! 

If  the  report  is  written  to  an  output  file,  it  may  be  shared 
with  word  processing  or  other  application  programs.  Refer 
to  Section  5  of  the  R:base  user  manual  for  a  description  of 
the  report  generation  process  or  use  the  HELP  REPORTS 
command.  ADV.RPT1 ,  ADV.RPT2,  ADV.RPT3,  ARES. RPT,  TOP. RPT 1 , 
and  T0P.RPT2  are  examples  of  report  outputs  (see  Printouts 
B.15  to  B. 1 8) . 


EXITING  R:BASE 

To  leave  R:base  and  return  to  the  command  level,  type 
EXIT  (RETURN].  The  system  will  respond  with  an  exit  message 
and  the  COMMAND  prompt,  and  all  modifications  to  the 
database  will  be  written  to  disk  files. 

If  the  program  or  system  crashes,  or  Rsbase  is  exited 
without  using  the  EXIT  command,  a  system  lock  may  occur. 

This  is  indicated  by  a  "Waiting  for  access..."  message  when 
you  are  the  only  user.  To  free  a  locked  system,  exit  to  the 
command  level,  delete  database  file  dbname4.RBS  and  index 
file  dbname4.IND  of  the  locked  database,  and  reload  R:base. 


BACK-UP  COPY 


To  make  a  back-up  copy  o-f  R:base  database  -files,  use 
the  ISAM  copy  command.  At  the  COMMAND  prompt,  type  ISAM 
COPY  [RETURN].  For  example: 


ISAM 

COPY 

[RETURN] 

ISAM 

data 

se  t 

from 

dbnamel .RBS 

[RETURN] 

ISAM 

data 

se  t 

to 

[FO] <SYS>dbnamel .RBS  [GO] 

I  SAM 

COPY 

[RETURN] 

ISAM 

data 

se  t 

from 

dbname2.RBS 

[RETURN] 

ISAM 

data 

se  t 

to 

[ FO ] <SYS>dbname . RBS  [GO] 

ISf*1 

COPY 

[RETURN] 

ISAM 

data 

set 

from 

dbname3.RBS 

[RETURN] 

ISAM 

data 

se  t 

to 

[FO ] <SYS>dbname3.RBS  [GO] 

IStti 

COPY 

[RETURN] 

ISAM 

data 

set 

from 

dbname4.RBS 

[RETURN] 

ISAM 

data 

se  t 

to 

[ FO ] <SYS>dbname4 . RBS  [GO] 

Each  RBS  database  -file  will  be  copied  with  the  correspondi  ng 
index  -file.  The  R:base  RELOAD  and  UNLOAD  commands  may  also 
be  used  to  create  a  copy  o-f  the  database.  The  first  file 
contains  the  data  dictionary.  The  second  file  contains  the 
actual  data.  The  third  file  contains  the  KEY  index 
information.  The  fourth  file  contains  multi-user  locking 
i nf ormat i on . 


Table  B.l 


Command 

ASSIGN 

BUILD 

CHANGE 

COMPUTE 

DEFINE 


R:base  Commands 


Syn  tax 

ASSIGN  attname  TO  expression  IN  relname 
(WHERE. . . ) 

BUILD  KEY  FOR  attname  IN  relname 

CHANGE  attname  TO  value  (IN  relname) 
WHERE. . . 

COMPUTE  t COUNT]  attname 
MIN 
MAX 
A*JE 
SUM 
ALL 

FROM  relname  (WHERE...) 

DEFINE  ( dbname ) 

The  Following  commands  are  used  in 
conjunction  with  DEFINE: 

OWNER  password 

ATTRIBUTES 

attname  type  (length)  (KEY) 
RELATIONS 

relname  WITH  attnamel  ( at tname2 . . . ) 


RULES 

•error  message*  attname 


value  ( C AND! . . . ) 
OR 


[IN  relname!  CEQ) 
NE 
GT 
GE 
LT 
LE 

CONTAINS 

EXISTS 


Table  B.l  (Continued) 


Command 


DELETE 

EDIT 


ENTER 

EXIT 

FORMS 

HELP 

INPUT 


R:base  Commands 


Syntax 


RULES  (Continued) 

"error  message*  attnamel  IN  relname  (EQA) 

NEA 

GTA 

GEA 

LTA 

LEA 

attname2  IN  re1name2  ([AND]...) 

OR 


PASSWORDS 

RPW  FOR  relname  IS  password 
MPW  FOR  relname  IS  password 

DELETE  DUPLICATES  FROM  relname 

DELETE  KEY  FOR  attname  IN  relname 

DELETE  ROW(S>  FROM  relname  WHERE... 

EDIT  Cattnamel . . .]  FROM  relname 
ALL 

( SORTED  BY ... )  (WHERE...) 

EDIT  USING  formname 
( SORTED  BY ... )  (WHERE...) 

ENTER  formname 

EXIT 

FORMS 

HELP 

HELP  command 
INPUT  u-fn 
INPUT  TERMINAL 

INTERSECT  re  1  name  1  WITH  re1name2  FORMING 
relname 3  (USING  attnamel...) 


INTERSECT 


Table  B.l  (Continued) 


Command 

JOIN 


LI  ST  ATT 
LISTREL 

LOAD 


NEWPAGE 

OPEN 

OUTPUT 


PRINT 


R:base  Commands 

Syntax 

JOIN  relnamel  USING  attnamel  WITH 
relname2  USING  attname2  FORMING  relname  3 
(WHERE  CEQ] . . . ) 

NE 

6T 

GE 

LT 

LE 

L I  ST ATT 
LISTREL 

LISTREL  relname 
LISTREL  ALL 

LOAD  relname  (FROM  u-fn)  (USING  attnamel.. 

LOAD  relname  WITH  PROMPTS  (USING  attnamel 

CHECK 

NOCHECK 

FILL 

NOFILL 

NEWPAGE 

OPEN  dbname 

OUTPUT  (u-fn) 

OUTPUT  TERMINAL  (WITH  PRINTER) 

OUTPUT  PRINTER  (WITH  TERMINAL) 

OUTPUT  (ufn)  CWITH  TERMINAL] 

WITH  PRINTER 
WITH  BOTH 

PRINT  reportname  (SORTED  BY...)  (WHERE... 


Table  B.l  (Continued) 


Command 

PROJECT 

PROMPT 

RELOAD 

REMOVE 

RENAME 


REPORTS 

SELECT 


SET 


R:base  Commands 


Syntax 


PROJECT  relnamel  FROM  relname2  USING 
Cattnamel  ...3  (SORTED  BY. ..) (WHERE. .. ) 
ALL 

PROMPT  ( c  omman d ) 

RELOAD  newdbname 
REMOVE  re  1  name 

RENAME  (ATTRIBUTE)  attnamel  TO  attname2 
(IN  relname) 

RENAME  OWNER  oldname  TO  newname 
RENAME  RELATION  relnamel  TO  relname2 


REPORTS 

SELECT  ALL  <*S)  FROM  relname 


SELECT  attnamel  (attname2. . . >  FROM  relname 
(SORTED  BY  ...)  (WHERE...) 

SELECT  ALL  FROM  relname  (SORTED  BY...) 
(WHERE  . . . ) 


SET  character  =  newvalue 


Special  characters  are: 

BLANK 

DOLLAR  * 

C0M1A  , 

PLUS  + 

QUOTES  ■ 

SEMI  ; 

SET  Keyword  newvalue 


Special  Keywords  are: 


USER 

ECHO 

BELL 

DATE 

CASE 

AUTOSKIP 

LINES 

RULE 

REVERSE 

WIDTH 

NULL 

Table  B.l  (Continued) 


Rsbase  Commands 


Command 

SHOW 


SORT 

SUBTRACT 

TALLY 

UNION 

UNLOAD 


USER 

WHERE 


Syntax 


SHOW  [special  character] 
keyword 

SHOW  RULES 

SHOW  USER 

SORTED  BY  attnamel  [  =  A3 

*  D 

<attname2  [=  A3) 

=  D 

SUBTRACT  re  1  name  1  FROM  relname2  FORMING 
relname3  (USING  attnamel...) 

TALLY  attname  FROM  relnaroe  (WHERE...) 

UNION  re  1  name  1  WITH  relname2  FORMING 
relname3  (USING  attnamel...) 

UNLOAD  SCHEMA  (FOR  re  1  name) 

UNLOAD  DATA  (FOR  re 1  name)  (USING 
[attnamel...])  ( SORTED  BY ... )  (WHERE...) 
ALL 

UNLOAD  ALL  (FOR  re  1  name) 

USER  password 

WHERE  condi tionl  ([AND3  condi t i on2. .. ) 

OR 

Condi t i ons  are : 
attname  EXISTS 
attname  FAILS 
attname  EQ  value 
attname  NE  value 
attname  GT  value 
attname  GE  value 
attname  LT  value 
attname  LE  value 
attname  CONTAINS  value 


Continued  on  next  page 


Table  8.1  (Continued) 
R:base  Commands 

Syntax 

WHERE  (Contiued) 
attnamel  EQA  attname2 
attnamel  NEA  attname2 
attnamel  GTA  attname2 
attnamel  GEA  attname2 
attnamel  LTA  attname2 
attnamel  LEA  attname2 
LIMIT  EQ  value 


Printout  B.l 


Listing  o-f  THESIS  Database  Rules 

1.  A DUNUM  IN  ADVISOR  EXISTS 

Message:  ADVISOR  NUMBER  MUST  »*5>VE  A  VALUE 

2.  TOPNUM  IN  TOPIC  EXISTS 

Message:  TOPIC  NUMBER  MUST  HAVE  A  VALUE 

3.  A DUNUM  IN  ADVISOR  NEA  A DUNUM  IN  ADVISOR 
Message:  YOU  ARE  ENTERING  A  DUPLICATE  ADV  NUMBER 

4.  TOPNUM  IN  TOPIC  NEA  TOPNUM  IN  TOPIC 

Message:  YOU  ARE  ENTERING  A  DUPLICATE  TOPIC  NUMBER 

5.  STATUS  IN  ADVISOR  EQA  STATUS  IN  STL I  ST 
Message:  STATUS  t**Y  BE  A  Q,A,I,C,  OR  P  ONLY 


Printout  B.2 
Example  o-f  DEFINE 


R>  DEFINE  THESIS 
Database  exists 

Begin  R:base  Database  De-f  i  n  i  t  i  on 
D>  ATTRIBUTES 
D>  STATUS  TEXT  1  KEY 
D>  STNAME  TEXT  20 
D>  RELATIONS 

D>  STL I  ST  WITH  STATUS  STNAME 
D>  RULES 

D>  "STATUS  MAY  BE  Q,A,I,C,  OR  P  ONLY"  STATUS  IN  ADVISOR  + 
EQA  STATUS  IN  STL I ST 
D>  END 

End  R:base  Database  Definition 


Printout  B.3 


Attributes  in  Relation  ADVISOR 


#  Name  Type 


1 

ADVNUM 

TEXT 

2 

STATUS 

TEXT 

3 

PHONE 

TEXT 

4 

ROOM 

TEXT 

5 

BLDG 

TEXT 

6 

0FFSYM 

TEXT 

7 

FNAME 

TEXT 

8 

LNAME 

TEXT 

9 

RANK 

TEXT 

10 

JOBTITLE 

TEXT 

11 

EDDATE1 

TEXT 

12 

DEGREE 1 

TEXT 

13 

MAJOR 1 

TEXT 

14 

SCHOOL  1 

TEXT 

15 

TH/D I SI 

TEXT 

16 

EDTEXT1 

TEXT 

17 

EDDATE2 

TEXT 

18 

DEGREE2 

TEXT 

19 

MAJ0R2 

TEXT 

20 

SCH00L2 

TEXT 

21 

TH/DIS2 

TEXT 

22 

EDTEXT2 

TEXT 

23 

EDDATE3 

TEXT 

24 

DEGREE3 

TEXT 

25 

MAJ0R3 

TEXT 

26 

SCH00L3 

TEXT 

27 

TH/D I S3 

TEXT 

28 

EDTEXT3 

TEXT 

29 

EXPDATE1 

TEXT 

30 

EXPTEXT1 

TEXT 

31 

EXPDATE2 

TEXT 

32 

EX  PT  EXT  2 

TEXT 

33 

EXPDATE3 

TEXT 

34 

EXPTEXT3 

TEXT 

35 

EXPDATE4 

TEXT 

36 

EXPTEXT  4 

TEXT 

37 

EXPDATE5 

TEXT 

38 

EXPTEXT  5 

TEXT 

39 

PUB1 

TEXT 

40 

PUB2 

TEXT 

Length  KEY 

4  characters  Y 

1  characters 
8  characters 
4  characters 

4  characters 
10  characters 
10  characters 
15  characters 

7  characters 
65  characters 

2  characters 

5  characters 
40  characters 
35  characters 

1  characters 
50  characters 

2  characters 
5  characters 

40  characters 
35  characters 

1  characters 
50  characters 

2  characters 
5  characters 

40  characters 
35  characters 
1  characters 
50  characters 
5  characters 
65  characters 
5  characters 
65  characters 
5  characters 
65  characters 
5  characters 
65  characters 
5  characters 
65  characters 
158  characters 
158  characters 


Continued  on  next  page 
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Printout  B.3  (Continued) 


Attributes  in  Relation  ADVISOR 


M 

Name 

Type 

Length 

41 

P0SIT1 

TEXT 

10 

characters 

42 

0RGNAME1 

TEXT 

30 

charac  ters 

43 

P0SIT2 

TEXT 

10 

charac  ters 

44 

0RGNAME2 

TEXT 

30 

characters 

45 

AREA1 

TEXT 

50 

charac  ters 

4  6 

AREA2 

TEXT 

50 

charac  ters 

47 

AREA3 

TEXT 

50 

characters 

Printout  B.4 


Attributes  in  Relation  ARESS 


# 

Name 

Type 

Length 

1 

ADLNUM 

TEXT 

4 

characters 

2 

LNAME 

TEXT 

15 

char acters 

3 

AREA 

TEXT 

50 

characters 

Printout  B.5 

Attributes  in  Relation  CATLIST 


KEY 


KEY 


#  Name 


Type 


Length 


KEY 


Printout  B.7 

Attributes  in  Relation  STLIST 
#  Name  Type  Length  KEY 

1  STATUS  TEXT  1  characters 

2  ST1**1E  TEXT  20  characters 


Printout  B.8 

Attributes  in  Relation  TOPIC 


41 

Name 

Type 

Length 

1 

TOPNUM 

TEXT 

4 

charac  ters 

2 

CATNUM 

TEXT 

2 

characters 

3 

SEQNUM 

TEXT 

3 

charac  ters 

4 

FAC1 

TEXT 

4 

char ac  ters 

5 

FAC2 

TEXT 

4 

characters 

6 

FAC3 

TEXT 

4 

characters 

7 

TITLE 

TEXT 

70 

characters 

8 

ABSTRACT 

TEXT 

790 

characters 

9 

BACK1 

TEXT 

4 

characters 

10 

BACK2 

TEXT 

4 

characters 

11 

TDATA 

TEXT 

158 

characters 

12 

EXPl 

TEXT 

4 

characters 

13 

EXP2 

TEXT 

4 

charac  ters 

14 

KEY1 

TEXT 

2 

characters 

15 

KEY2 

TEXT 

2 

charac  ters 

16 

KEY3 

TEXT 

2 

characters 

Attributes  in  Relation  TOPOUT 


# 

Name 

Type 

Length 

1 

TOPNUM 

TEXT 

4 

characters 

2 

CATNUM 

TEXT 

2 

characters 

3 

SEQNUM 

TEXT 

3 

charac  ters 

4 

FAC1 

TEXT 

4 

characters 

5 

FAC2 

TEXT 

4 

charac  ters 

6 

FAC3 

TEXT 

4 

charac  ters 

7 

TITLE 

TEXT 

70 

characters 

8 

ABSTRACT 

TEXT 

790 

characters 

9 

BACK1 

TEXT 

4 

characters 

10 

BACK2 

TEXT 

4 

characters 

11 

TDATA 

TEXT 

158 

characters 

12 

EXP1 

TEXT 

4 

characters 

13 

EXP2 

TEXT 

4 

characters 

14 

KEY1 

TEXT 

2 

characters 

15 

KEY2 

TEXT 

2 

characters 

16 

KEY3 

TEXT 

2 

characters 

17 

F1ADUNUM 

TEXT 

4 

characters 

18 

FI LNAME 

TEXT 

15 

charac  ters 

19 

F1FNAME 

TEXT 

10 

characters 

20 

FI  RANK 

TEXT 

7 

characters 

21 

FIOFFSYM 

TEXT 

10 

characters 

22 

F2ADVNUM 

TEXT 

4 

characters 

23 

F2LNAME 

TEXT 

15 

characters 

24 

F2FNAME 

TEXT 

10 

characters 

25 

F2RANK 

TEXT 

7 

characters 

26 

F20FFSYM 

TEXT 

10 

characters 

27 

F3ADVNUM 

TEXT 

4 

charac  ters 

28 

F3LNAME 

TEXT 

15 

charac  ters 

29 

F3FNAME 

TEXT 

10 

characters 

30 

F3RANK 

TEXT 

7 

charac  ters 

31 

F30FFSYM 

TEXT 

10 

characters 

32 

B1ADUNUM 

TEXT 

4 

characters 

33 

B1LNAME 

TEXT 

15 

characters 

34 

BiFNAME 

TEXT 

10 

characters 

35 

B1 RANK 

TEXT 

7 

characters 

36 

B10FFSYM 

TEXT 

10 

characters 

37 

B IPHONE 

TEXT 

8 

characters 

38 

B2ADVNUM 

TEXT 

4 

characters 

39 

B2LNAME 

TEXT 

15 

characters 

40 

B2FJWIE 

TEXT 

10 

charac  ters 

41 

B2RANK 

TEXT 

7 

characters 

42 

B20FFSYM 

TEXT 

10 

characters 

43 

B2PH0NE 

TEXT 

8 

characters 

Continued  on  next  page 


Printout  B.?  (Continued) 


Attributes  in  Relation  TOPOUT 


* 

Name 

Type 

Length 

44 

E1ADVNUM 

TEXT 

4 

charac ters 

45 

E1LNAME 

TEXT 

15 

characters 

4  6 

El FNAME 

TEXT 

10 

characters 

47 

El  RANK 

TEXT 

7 

characters 

48 

E10FFSYH 

TEXT 

10 

characters 

49 

El  PHONE 

TEXT 

8 

characters 

50 

E2ADVNUM 

TEXT 

4 

characters 

51 

E2LNAME 

TEXT 

15 

characters 

52 

E2FNAME 

TEXT 

10 

characters 

53 

E2RANK 

TEXT 

7 

characters 

54 

E20FFSYM 

TEXT 

10 

characters 

55 

E2PH0NE 

TEXT 

8 

characters 

PRINTOUT  B. 10 


Listing  o-f  Relation  CATLIST 


CATNUM  CATNAME 


01  CIVIL  ENGINEERING 

02  CONTRACTS 

03  COST  ESTIMATION 

04  DISTRIBUTION 

05  ECONOMIC  ANALYSES 

06  ENERGY/ENV I RONM ENT/ SAFETY 

07  HUMAN  RESOURCES/ORGANIZATIONAL  BEHAVIOR 

08  INTERNATIONAL  LOGISTICS 

09  MAINTENANCE 

10  MANAGEMENT  INFORMATION/DECISION  SUPPORT  SYSTEMS 

11  MANUFACTURING 

12  RESOURCE/F I NANC I AL  MANAGEMENT 

1 3  SPACE  SYSTEMS 

14  SUPPLY/ INVENTORY  REQUIREMENTS 

15  SYSTEMS  ACQUISITION 

1 6  TRANSPORTAT I  ON 

17  OTHER  MANAGEMENT  TOPICS 


Printout  B.ll 

Listing  o-f  Relation  STLIST 
STATUS  STNAME 


Q  QUALIFIED 

A  ADJUNCT  READER 

I  INTERN 

C  COMMITTEE  MEMBER 

P  PENDING 

-0-  BLANK 


Printout  B.12 


Listing  o-f  Relation  KEYLIST 

KETNUM  KEYWORD 


01 

02 

03 

04 

05 

06 

07 

08 

09 

10 

11 

12 

13 

14 

15 

16 

17 

18 

1 9 

20 
21 
22 

23 

24 

25 

26 

27 

28 

29 

30 

31 

32 

33 

34 

35 

36 

37 

38 

39 

40 


ACQUISITION 

AIRCRAFT  DAMAGE  REPAIR 

AIRLIFT 

APPLIED  MATHEMAT I CS 

ARTIFICIAL  INTELLIGENCE 

CAPABILITY  ASSESSMENT 

COMMUNICATIONS 

COMPUTER  AIDED  DESIGN 

COMPUTER  BASED  TRAINING 

COMPUTER  SOFTWARE 

CONSTRUCTION  MANAGEMENT 

CONFIGURATION  MANAGEMENT 

CONTINGENCY  ENGINEERING 

CONTRACT  ADM INI  STRATI  ON/MANAGEMENT 

CONTRACT  LAW 

CONTROL  THEORY 

COST  ANALYSI S 

DECISION  MAKING 

DISTRIBUTION  MANAGEMENT 

ECONOMETRIC  APPLICATIONS 

ECONOMICS 

ENERGY 

ENGINEERING  MANAGEMENT 
ENVIRONMENTAL  SYSTEMS 
EXPERIMENTAL  DESIGN 
FINANCIAL  MANAGEMENT 
FOREIGN  MILITARY  SALES 
FREIGHT  FORWARDING  INITIATIVES 
INDUSTRIAL  ENGINEERING 
INFORMATION  SYSTEMS 
INITIAL  PROVISIONING 
INTERNATIONAL  LOGISTICS 
LABOR  RELATIONS 
LEGAL  MATTERS 
LOGISTICS  EVOLUTION 
LOGISTICS  PLANNING 
LOGISTICS  SUPPORT  < GENERAL) 
LOGISTICS-SYSTEM,  HISTORY 
MAINTENANCE  MANAGEMENT 
MANPOWER 


69 


Printout  B.12  (Continued) 


Listing  o-f  Relation  KEYLIST 


KETNUM  KEYWORD 


41  MAN/MACHINE  INTERFACE 

42  MICROPROCESSOR/COMPUTER  CONTROLLERS 

43  MISSILES  < I  CBM) 

44  MODELING 

45  MODELING!  PHYSICAL  +  CONTROL 

4 6  NATIONAL  POLICY 

47  OPERATIONS  RESEARCH 

48  OPERATIONS  STRATEGY  AND  TACTICS 

49  OPTIMAL  ESTIMATION  AND  STOCHASTIC  CONTROL 

50  ORGANIZATIONAL  THEORY  AND  BEHAVIOR 

51  OVERPRICING 

52  PERFORMANCE  MEASUREMENT 

53  PERSONNEL  SYSTEMS 

54  PRODUCTION  MANAGEMENT 

55  PRODUCTIVITY 

56  PROJECT  MANAGEMENT 

57  QUALITY 

58  RAILROAD  LOGISTICS 

59  RELIABILITY 

60  RESEARCH  METHODS 

61  RESOURCE  ALLOCATION  (EMPLOYMENT  OF  FORCES) 

62  SOIL/ PAVEMENTS 

63  SYSTEMS  MANAGEMENT 

64  SYSTEMS  SIMULATION  TECHNIQUES 

65  TECHNICAL  ORDER  ACQUISITION 

66  TECHNICAL  WRITING 

67  TECHNOLOGY,  DUAL  PURPOSE 

68  TELEVISION,  INSTRUCTIONAL 

69  TRAINING 

70  TRANSPORTATION  MANAGEMENT 

71  VEHICLE  DESIGN 

72  VEHICLE  MAINTENANCE 

73  WOMEN  IN  THE  MILITARY 

99  -0- 


70 


Printout  B.13 


Listing  of  RESEARCH. RPT 


SET  ECHO  ON 

*(THI S  PROGRAM  GENERATES  A  LIST  OF  RESEARCH  INTERESTS  AND  + 
ADVISORS) 

*<  ) 

REMOVE  ARES5 

PROJECT  ARES1  FROM  ADVISOR  USING  ADVNUM  LNAME  AREA1  WHERE  + 
AREA1  EXISTS  AND  STATUS  EXISTS 
PROJECT  ARES2  FROM  ADVISOR  USING  ADVNUM  LNAME  AREA2  WHERE  + 
AREA2  EXISTS  AND  STATUS  EXISTS 
PROJECT  ARES3  FROM  ADVISOR  USING  ADVNUM  LNAME  AREA3  WHERE  + 
AREA3  EXISTS  AND  STATUS  EXISTS 
RENAME  AREA1  TO  AREA  IN  ARES1 
RENAME  AREA2  TO  AREA  IN  ARES2 
RENAME  AREA3  TO  AREA  IN  ARES3 
UNION  ARES1  WITH  ARES2  FORMING  ARES4 
UNION  ARES3  WITH  ARES2  FORMING  ARES5 
REMOVE  ARES1 
REMOVE  ARES2 
REMOVE  ARES3 
REMOVE  ARES4 

DELETE  DUPLICATES  FROM  ARES5 
PRINT  ARES. RPT  SORTED  BY  AREA  LNAME 
*<  ) 

*<IF  YOU  WISH  A  PRINTED  COPY  TYPE:  > 

*<  OUPUT  PRINTER  ) 

*< PRINT  ARES. RPT  SORTED  BY  AREA  U**1E> 

*< OUTPUT  TERMINAL  ) 

*<  ) 

SET  ECHO  OFF 
INPUT  TERMINAL 
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1JLA1 A  ikT  Am 


Listing  o-f  TOPIC. RPT 


SET  ECHO  ON 

*<THI S  PROGRAM  CREATES  THE  RELATION  TOPOUT) 

*<  ) 

REMOVE  TOPOUT 

PROJECT  ATEMP1  FROM  ADVISOR  USING  ADVNUM  LNAME  FNAME  RANK  + 
OFFSYM  SORTED  BY  ADVNUM 

JOIN  TOPIC  USING  FAC1  WITH  ATEMP1  USING  ADVNUM  FORMING  + 
TTEMP1 

RENAME  ADVNUM  TO  FI ADVNUM  IN  TTEMP1 
RENAME  LNAME  TO  FI LNAME  IN  TTEMP1 

RENAME  FNAME  TO  FI FNAME  IN  TTEMP1 

RENAME  RANK  TO  FI  RANK  IN  TTEMP1 

RENAME  OFFSYM  TO  FI OFFSYM  IN  TTEMP1 

JOIN  TTEMP1  USING  FAC2  WITH  ATEMP1  USING  ADVNUM  FORMING  + 
TTEMP2 

REMOVE  TTEMP1 

RENAME  ADVNUM  TO  F2ADVNUM  IN  TTEMP2 

RENAME  LNAME  TO  F2LNAME  IN  TTEMP2 

RENAME  FNAME  TO  F2FNAME  IN  TTEMP2 

RENAME  RANK  TO  F2RANK  IN  TTEMP2 

RENAME  OFFSYM  TO  F20FFSYM  IN  TTEMP2 

JOIN  TTEMP2  USING  FAC3  WITH  ATEMP1  USING  ADUNUM  FORMING  + 
TTEMP2 

REMOVE  TTEMP2 

RENAME  ADVNUM  TO  F3ADVNUM  IN  TTEMP3 

RENAME  LNAME  TO  F3LNAME  IN  TTEMP3 

RENAME  FNAME  TO  F3FNAME  IN  TTEMP3 

RENAME  RANK  TO  F3RANK  IN  TTEMP3 

RENAME  OFFSYM  TO  F30FFSYM  IN  TTEMP3 

REMOVE  ATEMP1 

PROJECT  ATEMP2  FROM  ADVISOR  USING  ADVNUM  LNAME  FNAME  RANK  + 
OFFSYM  PHONE  SORTED  BY  ADVNUM 
JOIN  TTEMP3  USING  BACK!  WITH  ATEMP2  USING  ADVNUM  FORMING  + 
TTEMP4 

REMOVE  TTEMP3 

RENAME  ADVNUM  TO  B1 ADVNUM  IN  TTEMP4 

RENAME  LNAME  TO  BILNAME  IN  TTEMP4 

RENAME  FNAME  TO  B1 FNAME  IN  TTEMP4 

RENAME  RANK  TO  BIRANK  IN  TTEMP4 

RENAME  OFFSYM  TO  B1 OFFSYM  IN  TTEMP4 

RENAME  PHONE  TO  B1 PHONE  IN  TTEMP4 

JOIN  TTEMP4  USING  BACK2  WITH  ATEMP2  USING  A DUNUM  FORMING  + 
TTEMP5 

REMOVE  TTEMP4 

RENAME  ADVNUM  TO  B2ADVNUM  IN  TTEMP5 
RENAME  LNAME  TO  B2LNAME  IN  TTEMP5 
RENAME  FNAME  TO  B2FN**!E  IN  TTEMP5 


Printout  B.14  (Continued) 


Listing  o-f  TOPIC. RPT 

RENAME  RANK  TO  B2RANK  IN  TTEMP5 
RENAME  OFFSYM  TO  B20FFSYM  IN  TTEMP5 
RENAME  PHONE  TO  B2PH0NE  IN  TTEMP5 

JOIN  TTEMP5  USING  EXP1  WITH  ATEMP2  USING  ADVNUM  FORMING  + 
TTEMP6 

REMOVE  TTEMP5 

RENAME  ADVNUM  TO  El ADVNUM  IN  TTEM P6 

RENAME  LNAME  TO  E1LNAME  IN  TTEMP6 

RENAME  FNAME  TO  E1FNAME  IN  TTEMP6 

RFNAME  RANK  TO  E1RANK  IN  TTEMP6 

RENAME  OFFSYM  TO  El OFFSYM  IN  TTEMP6 

RENAME  PHONE  TO  El  PHONE  IN  TTEMP6 

JOIN  TTEMP6  USING  EXP2  UITH  ATEMP2  USING  ADVNUM  FORMING  ♦ 
TOPOUT 

REMOVE  ATEMP2 
REMOVE  TTEMP6 

RENAME  ADVNUM  TO  E2ADVNUM  IN  TOPOUT 

RENAME  LNAME  TO  E2LNAME  IN  TOPOUT 

RENAME  FNAME  TO  E2FNAME  IN  TOPOUT 

RENAME  RANK  TO  E2RANK  IN  TOPOUT 

RENAME  OFFSYM  TO  E20FFSYM  IN  TOPOUT 

RENAME  PHONE  TO  E2PH0NE  IN  TOPOUT 

*<  ) 

*< RELATION  TOPOUT  IS  READY  TO  PRINT  OUT) 

SET  ECHO  OFF 
INPUT  TERMINAL 


Sample  Output  -from  ADV.RPT1  and  ADV.RPT2 

STATUS:  Q 
TEL# :  5-3944 
ROOM:  213 
BLDG:  641 
SYMBOL:  LSP 

ADKINS  ,  httJ 


Professor  of  Production  Management 


NAME  &  RANK:  JOEL  E. 

ACADEMIC  RANK/ 

JOB  TITLE:  Assistant 

EDUCATION: 


1971  MS  Industrial  Management 

University  of  North  Dakota  TH/DIS: 

Independent  Research  Paper 
1966  BBA  Industrial  Management  TH/DIS: 

University  of  New  Mexico 

19 

TH/DIS: 


RELEVANT  EXPERIENCE: 

1983-  Assistant  Professor,  Department  of  Contracting 
Man  ageme  n  t ,  AF I T 

1980-83  Instructor,  Department  of  Contracting  Management, 
AFIT 

1976-80  Chief  of  Govt  Furn  Prop  Mgt  Div,  Strat  Systems  SPO, 
UPAFB 

1975-76  AFIT  Education  wi thlndustry,  Lockheed  Missile  and 
Space  Co 

1971-75  Programs  Planning  Mgr,  Space  and  Missile  Center, 
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